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Executive  Summary 


Problem  Definition  The  Army’s  Program  Executive  Office  (PEO)  -  Soldier  has  the  complex  task  of  acquiring  and 
integrating  a  system  of  soldier  equipment  that  meets  validated  soldier  mission  requirements.  In  order  to  better 
assess  trade-offs  in  different  soldier  architectures,  they  seek  an  improved  simulation  capability  that  better  rep¬ 
resents  the  individual  soldier  on  the  battlefield.  No  single  model  provides  this  capability.  They  are  pursuing  a 
strategy  of  integrating  three  different  simulation  models  to  take  advantage  of  the  strengths  of  each.  These  mod¬ 
els  are  the  Infantry  Warrior  Simulation  (IWARS),  One  Semi -Automated  Eorces  (OneSAE),  and  the  Combined-Arms 
Analysis  Tool  for  the  21st  Century  (COMBAT^^).  After  achieving  real-time  integration  of  the  models  using  the 
High  Level  Architecture  (HLA ),  this  year’s  focus  was  to  leverage  that  architecture  in  order  to  simulate  information- 
enabled  command  and  control  for  the  dismounted  fight.  This  modeling  capability  opens  the  door  for  analysis 
of  the  unit-level  effects  of  ground  soldier  command  and  control  equipment  such  as  the  Land  Warrior  or  Ground 
Soldier  System  (GSS). 


Technical  Approach  The  approach  to  this  modeling  integration  was  to  break  down  the  overarching  integration 
task  into  a  series  of  discrete  tasks  that  could  be  performed  by  model  development  teams  involved  in  this  project. 

•  Build  automatic  federation  start/ stop  capabilities  into  the  models. 

•  Enable  IWARS  dismounts  to  be  carried  on  OneSAE  or  COMBAT  ™  vehicles. 

•  Integrate  a  validated  communications  model  into  the  architecture  to  assess  communications  effects  given 
certain  radio  capabilities,  environmental  characteristics,  and  tactical  distances  between  soldiers. 

•  Build  fire  support  modeling  into  the  federation. 

•  Build  situation  awareness  modeling  into  the  federation. 

•  Build  command  and  control  decision  making  into  the  federation. 

•  Model  soldier  casualties  at  a  higher  level  of  resolution  in  order  to  better  assess  effectiveness  of  different  soldier 
helmets  and  body  armor. 

•  Adapt  the  search  and  target  acquisition  process  within  the  model  to  better  capture  soldier  capabilities  such 
as  glimpsing  or  cuing. 

•  Model  soldier  power  consumption  during  the  mission  to  better  capture  the  effects  of  different  batteries  or 
power  consumption  profiles  of  soldier  equipment. 

•  Build  identification-friend- or-foe  (lEE)  capabilities  into  the  model  to  capture  the  effects  of  soldier-level  lEE 
systems. 


Results  The  focus  of  this  year’s  efforts  was  to  develop  a  federated  simulation  capability  for  dismounted  com¬ 
mand  and  control.  This  capability  is  built  upon  Research,  Development,  and  Engineering  Command’s  (RDECOM) 
Modeling  Architecture  for  Technology,  Research,  and  Experimentation  (MATREX)  and  their  Battle  Command  Man¬ 
agement  Services  (BCMS).  Eederation  management  and  design  was  supported  by  a  systems  engineering  process 
for  development  of  federated  simulations.  The  specification  borrows  ideas  from  the  systems  engineering  domain. 
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the  simulation  interoperability  domain,  and  the  software  engineering  domain.  It  has  activities  on  the  operational 
level  to  define  how  dismounted  soldiers  operate,  the  system  level  to  define  the  overall  architecture  of  the  feder¬ 
ation,  and  the  technical  level  to  fully  specify  requirement  to  model  developers.  Use  of  this  process  allowed  de¬ 
velopers  to  separate  operational  and  systems  concerns  from  their  technical  implementations  and  communicate 
more  effectively  in  the  design  process.  They  coded  their  implementations  more  efficiently  because  the  federation 
design  and  test  cases  communicated  the  requirements  more  completely.  These  requirements  were  fully  traceable 
to  both  the  operational  capabilities  represented  and  the  analysis  requirements. 

With  respect  to  federation  of  the  models,  integration  was  achieved  Avith  the  following  approaches: 

Information  Exchange  System  RDECOM’s  MATREX  architecture  was  used  to  ensure  interoperability  in  other 
RDECOM  and  Training  and  Doctrine  Command  (TRADOC)  federations. 

Environmental  Representation  In  order  to  ensure  the  federation  could  run  without  having  to  generate  multiple 
correlated  terrain  databases,  each  model  was  required  to  run  natively  using  only  OneSAE’s  Environmental 
Runtime  Component  (ERC). 

Entity  Representation  Entity  types  were  coordinated  between  models  using  equivalent  weapons  and  Army  Ma¬ 
teriel  Systems  Analysis  Activity  (AMSAA)  data.  Appropriate  MATREX  object  types  were  used  to  coordinate 
entity  states  during  federation  execution  for  dismounted  soldiers,  vehicles,  and  aircraft. 

Models  The  models  used  common  AMSAA  validated  target  acquisition,  direct  fire,  and  indirect  fire  lethality  mod¬ 
els.  Soldier  casualties  and  movement  were  represented  with  a  higher  level  of  fidelity  in  IWARS. 

Data  Collection  Data  collection  for  analysis  employed  a  mixed  strategy.  The  internal  data  collection  capabilities 
of  each  model  were  leveraged  where  possible,  however  some  data  required  network  based  data  collection 
tools  that  worked  at  the  federation  level. 

Time  Management  The  federation  synchronized  time  by  requiring  each  federate  to  run  in  real  time. 

By  the  end  of  the  year,  the  federation  demonstrated  a  significant  capability  to  model  dismounted  command  and 
control.  BCMS  tools  maintained  Situation  awareness  for  all  friendly  dismounts  and  vehicles,  regardless  of  which 
model  actually  owned  the  entity.  This  awareness  was  based  upon  the  passing  of  situation  reports  and  spot  reports 
on  the  communications  network  -  to  include  the  calculation  of  communications  effects.  Based  upon  the  situation 
awareness  of  small  unit  leaders,  a  fires  federate  automatically  generated  calls  for  fire  against  known  enemy  targets 
in  the  objective  area.  The  system  modeled  the  passing  of  fires  messages  and  the  clearance  of  fires  process  so 
that  rounds  were  delivered  only  when  the  appropriate  authority  received  the  fires  requests  and  cleared  friendly 
forces  from  the  target  area  using  current  situation  awareness.  In  addition,  a  command  and  control  federate  used 
current  situation  awareness  to  synchronize  the  maneuver  plan.  Small  unit  leaders  issued  commands  to  execute 
subsequent  phases  and  branches  of  the  operations  order  by  cross  referencing  their  situation  awareness  against  a 
decision  support  template  for  reactive  maneuver  decisions  during  the  fight. 

In  addition  to  these  command  and  control  capabilities,  the  following  advances  were  made: 

•  The  Brigade  and  Below  Propagation  and  Protocols  (B2P2)  model  developed  by  Army  Research  Lab  Surviv¬ 
ability/Lethality  Analysis  Directorate  (ARL-SLAD)  began  integration  as  a  MATREX  communications  federate. 
Integration  of  this  model  is  not  yet  complete.  In  addition,  an  integration  effort  has  been  started  with  the  Com¬ 
munications  Planner  for  Operational  and  Simulation  Effects  with  Realism  (COMPOSER)  model  developed  by 
the  Communications-Electronics  Research,  Development,  and  Engineering  Center  (CERDEC). 


•  Algorithms  have  been  developed  to  capture  dismounted  casualty  effects  with  higher  resolution,  especially 
with  respect  to  fragmentation. 

•  Search  and  target  acquisition  algorithms  have  been  developed  to  better  represent  soldier  level  glimpsing  and 
cuing  with  an  awareness  of  the  operational  environment. 

•  Power  consumption  algorithms  have  been  developed  for  soldier  equipment  that  allow  for  the  disabling  of 
equipment  used  by  simulated  soldiers  when  their  batteries  are  dead. 

•  Initial  studies  have  been  conducted  into  the  development  and  validation  of  IFF  algorithms. 

Given  achievement  of  these  capabilities,  efforts  for  the  upcoming  year  will  focus  on  analysis  tasks  in  support  of 
the  XM-25  Counter- Defilade  Target  Engagement  System  for  Project  Manager  Individual  Weapons  and  a  terrain 
analysis  capability  for  the  Land  Warrior  and  Ground  Soldier  System  for  Project  Manager  Ground  Soldier.  These 
analysis  tasks  will  require  representation  of  the  XM-25  in  each  of  the  models.  The  modeling  team  will  also  develop 
decision  models  for  route  planning  and  position  selection  based  on  automated  terrain  and  situation  analysis.  In 
addition,  the  federation  will  add  America’s  Army  as  a  game-based  virtual  federate  that  allows  a  human  player  to 
take  on  the  role  of  a  dismounted  soldier  in  the  scenario.  As  part  of  this  integration,  the  ballistic  dispersion  and 
damage  algorithms  from  OneSAF  will  be  used  to  calculate  ballistic  and  damage  effects  for  the  entities  modeled  in 
America’s  Army.  This  will  aid  verification  and  validation  of  this  virtual  federate. 
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1  BACKGROUND 


1  Background 

The  PEO  Soldier  Simulation  Road  Map  is  an  effort  by 
PEO  Soldier  to  develop  within  the  Army  a  capability  to 
model  the  effects  of  soldier  equipment  on  unit-level  ef¬ 
fectiveness  -  focused  at  platoon  and  below.  This  study 
is  the  sixth  year  of  collaborative  effort  between  Program 
Executive  Office  (PEO)  Soldier  and  the  West  Point  Oper¬ 
ations  Research  Center  (ORCEN).  Previous  studies  have 
led  this  effort  to  where  it  stands  today  During  the  first 
year,  the  ORCEN  analyzed  simulation  requirements  and 
recommended  a  3 -model  approach  integrating  IWARS, 
OneSAE,  and  COMBAT^^.  During  the  second  year,  OR¬ 
CEN  effort  was  focused  on  establishing  a  memorandum 
of  agreement  between  the  three  modeling  agencies  and 
mapping  soldier  equipment  lists  into  prioritized  mod¬ 
eling  requirements.  In  the  third  year  of  effort,  the  mod¬ 
eling  agencies  signed  the  agreements  and  started  pri¬ 
oritizing  their  work  into  common  environmental  and 
scenario  representations  that  would  enable  ‘‘soft”  link¬ 
ages  between  the  models.  In  the  fourth  year,  these 
“soft”  linkages  were  achieved,  allowing  scenarios  to  be 
run  in  one  model,  stopped,  passed  to  a  second  model, 
and  run  to  completion.  In  year  five  hard  linkages  were 
achieved  allowing  the  models  to  exchange  data  during 
run-time.  The  sixth  year  leveraged  these  real-time  link¬ 
ages  to  achieve  command  and  control  modeling  capa¬ 
bilities  for  the  federation. 

In  November  of  2003,  Brigadier  General  James  Moran, 
PEO  Soldier,  commissioned  the  ORCEN  to  develop  a 
model,  or  family  of  models,  that  would  support  PEO 
Soldier  decision  making  with  respect  to  soldier  equip¬ 
ment.  The  ORCEN,  working  within  the  PEO,  further 
defined  the  need  as,  “PEO  Soldier  needs  a  simula¬ 
tion  that  allows  the  evaluation  of  platoon  effectiveness 
based  upon  changes  in  Soldier  tactical  mission  sys¬ 
tem  (STMS)  characteristics.”  Eulfillment  of  this  need 
would  bring  the  PEO  in  line  with  the  Army’s  Simula¬ 
tion  and  Modeling  for  Acquisition,  Requirements,  and 
Training  (SMART)  program.  The  SMART  program  “in¬ 
volves  rapid  prototyping  using  M&S  [modeling  and  sim¬ 
ulation]  media  to  facilitate  systems  engineering  so  that 
materiel  systems  meet  users’  needs  in  an  affordable  and 
timely  manner  while  minimizing  risk  (AMSO,  2002).” 
Taking  this  need,  the  ORCEN  evaluated  a  series  of  al¬ 


ternatives  that  ranged  from  creating  a  brand  new  sim¬ 
ulation  to  adopting,  in  its  entirety,  an  existing  simula¬ 
tion.  The  team  concluded  that  while  developing  a  sin¬ 
gle  model  was  cost  and  time  prohibitive,  no  single  ex¬ 
isting  model  met  the  PEO’s  requirements.  They  recom¬ 
mended  a  federation  of  models  including  IWARS,  One¬ 
SAE,  and  COMBAT™.  PEO  Soldier  accepted  this  recom¬ 
mendation  and  asked  the  ORCEN  to  lead  the  effort  in 
building  a  team  to  develop  this  federation  (Tollefson  & 
Boylan,  2004). 

While  everyone  understood  the  need  for  a  federated 
modeling  solution,  the  composition,  type  of  integra¬ 
tion,  and  level  of  detail  for  the  federation  were  not  so 
simple  to  agree  upon.  The  ORCEN  worked  two  parallel 
efforts  from  June  2004  until  July  2005.  Eirst,  they  had  to 
establish  memoranda  of  agreement  that  would  enable 
funding  and  collaboration  within  this  project.  This  re¬ 
quired  significant  negotiation  between  PEO  Soldier,  the 
Natick  Soldier  Center  (developer  of  IWARS),  PEO  Simu¬ 
lation  Training  and  Instrumentation  (PEO-STRI  -  devel¬ 
oper  of  OneSAE),  and  Training  and  Doctrine  Command 
Analysis  Center  -  White  Sands  Missile  Range  (TRAC- 
WSMR  -  developer  of  COMBAT™).  Second,  they  had  to 
further  refine  the  analysis  requirements  for  the  federa¬ 
tion.  In  short,  PEO  Soldier  did  not  have  a  list  of  anal¬ 
ysis  requirements;  they  had  a  list  of  equipment.  The 
ORCEN  worked  with  the  PEO  to  categorize  and  stream¬ 
line  this  list  into  a  discrete  set  of  modeling  requirements 
that  could  be  implemented  by  the  members  of  the  fed¬ 
eration.  Once  these  requirements  were  understood,  it 
was  easier  for  the  modeling  agencies  to  agree  to  develop 
these  capabilities  (Martin,  2005). 

Given  an  agreement  to  work  together,  and  a  list  of  anal¬ 
ysis  needs,  the  next  significant  question  is  where  to 
start.  The  modeling  teams  first  came  together  under  the 
signed  agreements  in  2005.  However,  there  was  not  gen¬ 
eral  agreement  on  the  integration  technology  or  on  the 
initial  analysis  tasks.  The  ORCEN  worked  with  the  PEO 
to  select  from  the  list  of  analysis  requirements,  a  very 
short  list  of  equipment  and  associated  analysis  ques¬ 
tions.  Collectively,  the  group  decided  to  begin  effort  on 
“soft”  linkages.  In  other  words,  the  models  in  the  federa¬ 
tion  would  not  exchange  data  during  run-time.  Instead, 
they  would  agree  on  a  common  terrain  representation 
and  a  common  scenario  representation.  Using  these 
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representations,  different  models  would  take  over  the 
scenario,  run  a  portion  of  the  fight,  update  the  status  of 
the  combatants,  then  pass  that  information  to  another 
model.  Under  this  approach,  the  team  could  get  started 
more  quickly,  develop  a  working  relationship,  and  work 
out  challenges  to  an  eventual  “hard”  linkage  where  the 
models  exchanged  data  with  each  other  during  the  run. 
(Boylan,  2006). 

During  May  of  2007,  in  the  fourth  year  of  effort  for  this 
project,  the  modeling  team  achieved  a  “soft”  integra¬ 
tion  of  two  models,  IWARS  and  COMBAT™,  for  a  small 
room-clearing  scenario.  This  was  made  possible  by  the 
agreement  between  all  of  the  development  teams  to 
use  OneSAF’s  Environmental  Runtime  Component  for 
common  terrain  and  environment  representation.  They 
also  agreed  to  use  the  Military  Scenario  Definition  Lan¬ 
guage  (MSDL)  to  share  scenario  data.  Using  this  inte¬ 
gration,  the  ORCEN  analyst  was  able  to  collect  mission 
performance  data  for  the  simulation  run  using  a  2x2  fac¬ 
torial  design.  In  this  case,  he  represented  two  different 
levels  of  body  armor  and  night  vision  equipment  (Kram- 
lich,  2007).  This  proof-of-concept  integration  was  a  ma¬ 
jor  step  in  the  five-year  history  of  this  project.  The  three 
models,  selected  in  year  1,  came  together  with  a  com¬ 
mon  understanding  of  the  analysis  requirements,  es¬ 
tablished  in  year  2,  and  a  common  picture  of  the  inte¬ 
gration  requirements,  established  in  year  3.  Most  im¬ 
portant  in  this  successful  linkage  was  the  working  re¬ 
lationships  developed  by  the  modeling  teams  and  their 
commitment  to  the  tasks  at  hand. 

Much  of  the  focus  and  effort  for  academic  year  2008- 
2009  was  centered  on  developing  a  working  federation 
using  High  Level  Architecture.  A  decision  was  made 
early  in  the  year  to  use  Research,  Development,  and 
Engineering  Command’s  (RDECOM)  Modeling  Archi¬ 
tecture  for  Technology,  Research,  and  Experimentation 
(MATREX)  for  integration.  Their  federation  architec¬ 
ture  was  designed  to  support  the  Euture  Combat  Sys¬ 
tems  program,  so  it  had  the  greatest  support  for  ad¬ 
vanced  communications  and  command  and  control  in¬ 
teractions.  Both  IWARS  and  OneSAE  had  already  done 
development  to  support  the  MATREX  federation  object 
model.  Another  decision  was  made  early  in  the  year  to 
adopt  model  driven  architectures  (MDA)  to  drive  simu¬ 
lation  development.  In  this  manner,  high-level  activity 


diagrams  represented  the  battlefield  concepts.  These 
were  used  to  assign  activities  to  different  simulation 
models.  More  detailed  sequence  diagrams  showed  how 
the  federation  handled  these  activities  using  the  techni¬ 
cal  details  of  the  run-time  infrastructure  and  federation 
object  model.  This  communication  enabled  the  model¬ 
ing  teams  to  better  focus  their  efforts  on  code  develop¬ 
ment.  It  also  enabled  explanation  of  these  interactions 
to  those  who  could  not  read  the  code.  This  aids  verifi¬ 
cation  and  validation  of  the  models,  along  with  analy¬ 
sis.  By  the  end  of  the  year,  the  team  had  a  working  test 
scenario  in  which  OneSAE  controlled  the  vehicles  and 
indirect  fire  elements,  while  IWARS  controlled  the  dis¬ 
mounted  forces  moving  into  a  village  for  a  raid.  This 
architecture  supports  analysis  of  the  impact  of  soldier 
equipment,  to  include  weapons,  sensors,  body  armor, 
and  communications  gear,  on  the  dismounted  squad 
and  its  supporting  mounted  forces. 

The  successful  HLA  integration  laid  the  groundwork  for 
the  2008-2009  tasks  for  the  Simulation  Road  Map.  The 
task  lists  in  ANNEX  A  highlight  those  efforts  for  each 
component  model.  In  order  to  achieve  those  tasks,  the 
West  Point  Department  of  Systems  Engineering  devel¬ 
oped,  in  conjunction  with  the  Virginia  Modeling  Anal¬ 
ysis  and  Simulation  Center  (VMASC),  two  theoretical 
concepts  to  support  federation  development.  The  first 
of  these  is  SysHub,  a  set  of  six  engineering  requirements 
for  the  development  of  federated  simulation  models  in 
support  of  systems  of  systems  analysis.  A  second  sup¬ 
porting  concept,  a  systems  engineering  process  for  the 
development  of  federated  simulations,  defined  a  pro¬ 
cess  for  meeting  those  engineering  requirements.  Dur¬ 
ing  the  year,  the  development  team  followed  this  pro¬ 
cess.  They  began  with  an  operational  view  that  defined 
the  scenario  and  the  functional  capabilities  of  the  actual 
system.  A  systems  view  allowed  allocation  of  functional 
tasks  to  supporting  simulations  within  the  federation. 
The  technical  view  allowed  further  definition  of  the  in¬ 
tegration  requirements  via  sequence  diagrams  that  ref¬ 
erenced  the  data  structures  within  the  MATREX  feder¬ 
ation  object  model.  Erom  these  sequence  diagrams, 
the  ORCEN  developed  and  distributed  automated  test 
cases  to  better  define  the  integration  requirements  for 
each  supporting  simulation.  The  systems  engineering 
process  ensured  traceability  from  the  technical  require - 
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merits  all  the  way  up  to  the  operational  functions  and 
capabilities  of  the  simulated  system.  By  this  process, 
the  development  team  achieved  federated  simulation 
capabilities  for  situation  awareness,  communications, 
fires,  and  command  and  control.  This  allows  analysis 
of  the  combat  outcome  that  can  be  achieved  with  dif¬ 
ferent  dismounted  command  and  control  systems  is¬ 
sued  to  different  elements  of  the  dismounted  squad  and 
platoon.  This  development  was  orchestrated  in  accor¬ 
dance  with  the  project  plan  in  ANNEX  B. 

2  SysHub  -  Engineering  Require¬ 
ments  for  Federated  Simulation 

Systems  of  systems  integration  is  one  of  the  biggest 
challenges  facing  military  forces  today.  This  challenge 
exists  whether  the  integration  occurs  in  the  acquisition 
community  or  in  the  operational  environment.  Large 
acquisition  programs  such  as  PEO  Soldier  are  doing  par¬ 
allel  development  of  many  systems.  Architecture  and 
design  changes  in  one  system  have  ripple  effects  that 
propagate  across  all  of  the  systems  in  development  and 
to  the  environment.  This  creates  a  complex  network 
of  interactions  in  which  architectural  changes  to  one  of 
the  subsystems  impact  other  soldier  systems,  other  sys¬ 
tems  into  which  soldiers  must  integrate,  and  soldiers 
who  operate  the  system.  A  similar  problem  exists  in  the 
operational  community.  The  evolving  wartime  environ¬ 
ment  demands  a  series  of  parallel  training,  acquisition, 
and  fielding  initiatives  that  must  be  integrated.  Analysis 
of  these  interactions  demands  a  more  robust  and  recon- 
figurable  simulation  paradigm.  The  West  Point  Depart¬ 
ment  of  Systems  Engineering’s  SysHub  program  looks 
to  expand  the  research  base  and  body  of  knowledge  for 
modeling,  simulation,  and  analysis  to  support  systems 
of  systems  integration (Kewley  etal ,  2008). 

Eederated  simulations  must  be  as  agile,  robust,  and  in¬ 
teractive  as  the  operational  environment  they  support. 
Large  single  models  that  enable  analysis  of  systems 
of  systems  are  not  effective  because  no  single  model¬ 
ing  effort  can  account  for  all  of  the  complexities.  In¬ 
stead,  modeling  and  analysis  must  be  done  in  a  dis¬ 
tributed  and  parallel  fashion,  mirroring  the  develop¬ 


ment  of  training,  acquisition,  and  fielding  initiatives. 
This  leads  to  a  number  of  subsystem  models  that  effec¬ 
tively  analyze  different  domains.  In  order  to  support 
systems  of  systems  analysis,  subsystem  models  need 
to  be  federated.  Current  federation  architectures  such 
as  distributed  interactive  simulation  (DIS)  and  existing 
versions  of  high  level  architecture  (HLA)  support  inter¬ 
operability  in  the  military  fire  and  engagement  domain. 
Additional  interoperability  research  is  needed  to  sup¬ 
port  federations  of  models  that  examine  other  domains, 
such  as  command  and  control  and  human  behavior. 
In  addition,  architectural  modeling  processes  and  tools 
that  enable  agile  architecture  development  and  revi¬ 
sion  will  empower  federation  developers  to  ensure  that 
interactions  between  models  have  shared  meaning  in 
both  the  conceptual  and  technical  domains. 

SysHub  is  a  capability  to  rapidly  conceptualize,  develop, 
execute,  and  analyze  data  using  federated  simulation 
models.  This  concept  is  illustrated  in  Eigure  1.  At  the 
core  of  this  capability  is  a  set  of  engineering  capabili¬ 
ties.  The  outer  ring  shows  a  series  of  domains  in  which 
federated  models  have  proven  useful.  Within  that  ring, 
we  list  a  series  of  current  application  areas  from  those 
domains.  Eor  each  application,  a  different  federation  of 
models  must  be  developed  to  support  the  question  at 
hand.  These  federates  must  be  held  together,  concep¬ 
tually  and  technically,  by  the  engineering  capabilities  in 
the  center  of  Eigure  1.  These  are  the  key  research  areas 
that  enable  development  of  federated  models: 

Information  Exchange  System  The  capability  to  pass 
meaningful  information  between  federates  during 
the  simulation  run. 

Environmental  Representation  The  capability  for  fed¬ 
erates  to  reference  a  shared  and  correlated  envi¬ 
ronment  in  which  entities  interact. 

Entity  Representation  The  capability  for  federates  to 
referenced  shared  conceptually  aligned  informa¬ 
tion  about  entities  in  the  simulation.  Some  of  this 
representation  is  passed  via  the  information  ex¬ 
change  system. 

Models  Within  the  context  of  the  analysis  or  train¬ 
ing  question,  the  internal  models  of  each  federate 
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must  be  validated  and  coordinated  across  the  fed¬ 
eration. 

Data  Collection  The  capability  to  collect  meaningful 
information  from  the  simulation  run  in  the  con¬ 
text  of  the  analysis  question  or  training  objective 
for  which  the  federation  was  designed. 

Time  Management  The  capability  for  all  federates  to 
maintain  a  common  time  reference  in  order  to  syn¬ 
chronize  simulated  events. 


2. 1  Information  Exchange  System 

With  respect  to  software  systems,  interoperability  is 
‘The  ability  of  two  or  more  systems  or  components  to  ex¬ 
change  information  and  to  use  the  information  that  has 
been  exchanged  (Institute  for  Electrical  and  Electron¬ 
ics  Engineers,  1990).”  Data  standards  are  specific  agree¬ 
ments  between  agents  responsible  for  different  software 
subsystems  that  communicate  with  each  other  when 
functioning  as  parts  of  a  larger  system.  An  information 
exchange  system  provides  for  a  basic  level  of  interoper¬ 
ability  between  simulations.  It  is  a  necessary  condition 
for  any  higher  level  of  interoperability. 

Two  common  models  for  providing  interoperability  are 
the  Distributed  Interactive  Simulation  (DIS)  protocol 
(lEEE-SA  Standards  Board,  1998)  and  the  High  Level 
Architecture  (HLA)  (lEEE-SA  Standards  Board,  2000). 
These  are  established  Institute  for  Electrical  and  Elec¬ 
tronics  Engineers  (IEEE)  standards  for  allowing  simu¬ 
lations  to  share  information  at  run  time.  An  exam¬ 
ple  of  a  data  standard  is  the  defined  federation  object 
model  implemented  to  enable  a  specific  federation  in¬ 
stance  over  HLA.  Unfortunately  the  techniques  are  gen¬ 
erally  brittle  in  one  case  (DIS)  and  challenging  to  imple¬ 
ment  in  the  other  (HLA).  In  both  cases  the  tools  built  to 
perform  the  underlying  work,  such  as  communication 
across  the  nework  and  parsing  of  messages,  within  a 
federation  end  up  being  in  practice  custom  implemen¬ 
tations  built  for  a  specific  purpose. 

The  Army’s  experimentation  program  in  support  of 
transformation  significantly  challenged  the  existing 
federated  simulation  paradigm  (Hurt  etal ,  2006).  This 


program  had  a  need  for  the  aggregation  of  engineering- 
level  models  in  an  environment  that  supported  human- 
in-the-loop  interaction  and  a  robust  command  and 
control  environment.  The  MATREX  program  took  a 
systems  engineering  approach  to  attacking  these  chal¬ 
lenges  in  a  collective  environment  that  spanned  RDE- 
COM  in  the  context  of  systems  of  systems  analysis  and 
integration.  They  developed  not  only  an  HLA  based  in¬ 
formation  exchange  system,  but  also  the  tools  and  pro¬ 
cedures  required  to  support  integration  and  build  com¬ 
munity  acceptance  (Gallant  etal ,  2009). 

This  project  used  used  RDECOM’s  MATREX  toolkit  for 
integration.  Their  federation  architecture  was  designed 
to  support  several  other  research  and  development  pro¬ 
grams,  so  it  had  the  greatest  support  for  advanced  com¬ 
munications  and  command  and  control  interactions. 
Both  IWARS  and  OneSAE  had  already  done  develop¬ 
ment  to  support  the  MATREX  federation  object  model. 
Support  from  the  MATREX  program  has  allowed  this 
project  to  move  from  an  idea  to  a  reality  in  a  relatively 
short  fashion.  Key  MATREX  aspects  are: 

Community  acceptance  Due  to  the  fact  that  OneSAE 
and  IWARS  had  already  completed  MATREX  inte¬ 
gration  at  some  level  for  other  exercises,  it  was  a 
much  easier  sell  to  bring  these  programs  into  fur¬ 
ther  integration  using  this  architecture.  In  effect, 
MATREX  has  become  a  de  facto  standard  for  inte¬ 
gration  of  Army  simulations. 

Cadre  of  simulation  expertise  Once  we  decided  to 
perform  MATREX  integration,  the  MATREX  sup¬ 
port  team  was  an  invaluable  source  of  expertise 
and  training  that  allowed  us  to  solve  a  variety 
of  architecture  and  integration  problems.  They 
had  already  seen  many  of  our  problems  in  other 
communities  and  were  quickly  able  to  provide 
recommendations  for  solution. 

Existing  data  model  The  existing  data  model,  repre¬ 
sented  in  the  MATREX  Eederation  Object  Model,  is 
a  community  accepted  integration  model  that  has 
met  most  of  our  integration  needs  with  no  modifi¬ 
cation. 

Protocore  middleware  The  Protocore  middleware  li¬ 
brary  has  enabled  our  participating  simulation  de- 
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Figure  1:  SysHub  -  Engineering  capabilities  for  federated  simulations  in  support  of  systems  of  systems  analysis. 


velopers  to  easily  integrate  their  Java  or  C++  sim¬ 
ulations  without  having  to  worry  about  the  details 
of  encoding  and  passing  messages.  As  an  anecdo¬ 
tal  metric,  the  two  simulations  that  use  Proto  core 
typically  spend  most  of  their  time  during  our  in¬ 
tegration  events  dealing  with  the  handling  and  in¬ 
terpretation  of  MATREX  messages  internal  to  their 
models.  The  two  simulations  that  chose  not  to  use 
Protocore  are  many  months  behind  schedule  and 
have  still  not  successfully  integrated  at  any  of  our 
events.  They  spend  much  of  their  time  debugging 
the  encoding. 

Automated  test  cases  The  MATREX  Automated  Test 
Case  tool  allows  us  to  distribute  test  cases  with 
each  new  integration  task.  These  test  cases  provide 
unambiguous  messages  and  test  capabilities  to  our 
developers  which  prevents  costly  misunderstand¬ 
ings. 

Training  support  The  MATREX  team  has  offered  train¬ 
ing  courses  and  on-site  integration  support  that 
have  allowed  us  to  quickly  learn  and  integrate  their 
tools. 


Battle  command  The  MATREX  Battle  Command  Man¬ 
agement  Services  have  allowed  us  to  build  a  com¬ 
mon  operational  picture  that  sits  on  the  network 
as  opposed  to  being  internal  to  the  simulations. 
This  enables  simulation-independent  command 
and  control  and  assessment  of  the  knowledge  state 
of  entities  in  the  exercise. 

Government  owned  The  lack  of  license  fees  and  other 
charges  makes  MATREX  affordable  from  both  a 
cost  and  management  perspective. 

In  summary,  without  MATREX,  the  integration  would 
have  taken  up  to  six  additional  months,  and  the  solution 
would  be  a  fragile  “point  solution”  based  only  on  our  in¬ 
ternal  knowledge  and  only  on  the  needs  of  our  project. 
We  would  have  incurred  additional  costs  by  having  to 
hire  a  commercial  simulation  integration  company,  and 
we  would  have  adopted  their  tools  -  essentially  locking 
us  in  to  that  commercial  provider.  The  MATREX  tools 
are  a  great  solution  for  the  information  exchange  system 
of  any  federation,  but  especially  in  the  Army  research 
and  development  domain. 


5 


PEO  Soldier  Simulation  Road  Map  VI  -  Command  and  Control  Modeling 


2.2  Environmental  Representation 

In  many  simulation  abstractions,  entities  interact  with 
each  other  and  with  their  environment.  In  federated 
simulations,  it  is  not  common  for  the  models  to  share 
a  single  representation  of  the  environment  across  the 
network.  In  most  cases,  each  individual  model  has  its 
OAvn  internal  representation  of  that  environment.  If  the 
results  of  the  simulation  are  going  to  be  valid,  those  en¬ 
vironmental  representations  must  be  sufficiently  corre¬ 
lated  so  that  the  results  of  the  simulation  are  not  ob¬ 
scured  by  differences  in  these  representations. 

Environment  encompasses  natural  and  man  made 
physical  elements  of  the  battlespace  occurring  in  the 
terrain,  atmosphere,  ocean,  and  space  domains.  In  tra¬ 
ditional  modeling  and  simulation  taxonomies,  build¬ 
ings  and  land-based  infrastructure  fall  under  the  do¬ 
main  of  terrain.  This  typically  includes  features  that 
are  considered  more  persistent  over  time.  In  addi¬ 
tion,  those  things  such  as  weather  and  obscurants  that 
change  over  much  smaller  time  scales  are  also  impor¬ 
tant  elements  of  environment  that  must  be  captured  in 
its  representation. 

In  federating  different  applications,  it  is  key  that  the  en¬ 
vironment  is  correlated  for  meaningful  interchange  and 
execution  of  a  scenario.  This  is  a  particularly  challeng¬ 
ing  area  based  on  the  fact  that  there  often  are  differ¬ 
ent  means  of  defining  the  relief  (elevation  over  spatial 
extents  of  the  area  of  interest)  and  extracting  and  rep¬ 
resenting  features.  Different  simulations  often  use  dif¬ 
ferent  terrain  data  models  for  their  internal  representa¬ 
tions. 

Terrain  databases  created  for  different  applications  may 
or  may  not  be  created  from  the  same  source  data.  The 
source  data  may  be  of  different  resolutions  and  the 
techniques  for  sampling  and  integrating  data  may  be 
different.  Thus,  it  is  not  surprising  that  features,  such 
as  roads,  bridges,  rivers,  and  forested  areas,  that  are 
the  map  for  different  applications  do  not  nicely  over¬ 
lay  each  other.  Additionally,  if  the  surface  relief  is  rep¬ 
resented  differently  across  applications,  adjudication  of 
line- of- sight  and  other  interactions  with  the  terrain  be¬ 
come  problematic.  These  can  cause  major  issues  when 
federating  simulations.  There  is  a  need  for  entities  in 


the  simulation  to  have  the  same  notion  of  where  ele¬ 
ments  in  the  environment  are  and  to  execute  interac¬ 
tions  using  a  correlated  representation  of  that  environ¬ 
ment. 

The  terrain  data  models  include  features  such  as  road 
segment  or  surface  element.  These  will  have  further 
attribution  that  denotes  things  such  as  type  of  road  or 
soil  type.  Furthermore,  there  are  allowable  enumera¬ 
tions  for  road  type  and  for  soil  type.  Consider,  soil  type 
for  example.  Enumerations  might  be  those  denoted 
by  the  U.S.  Geological  Survey  (USGS)  soil  classifica¬ 
tions  or  they  might  be  more  simply  represented  as  sand, 
clay,  mud,  or  gravel.  If  linking  applications  using  these 
two  different  soil  type  enumerations  and  considering 
ground  vehicle  mobility,  it  is  important  to  understand 
how  this  affects  the  underlying  algorithms  computing 
mobility  and  how  this  affects  a  fair  fight,  interoperabil¬ 
ity,  and  correlation.  There  have  been  various  efforts  to 
standardize  data.  The  Synthetic  Environment  Data  Rep¬ 
resentation  and  Interchange  Specification  (SEDRIS)  is 
an  open  project  with  several  products  and  participates 
in  standards  development  (SEDRIS,  2007). 

The  correlated  generation  of  terrain  information  for 
simulation  databases  is  a  very  broad  and  complex  topic. 
There  are  three  options  with  respect  to  terrain  represen¬ 
tation.  The  first  option  is  to  have  each  model  interact 
with  terrain  using  copies  of  the  same  terrain  data  model 
and  associated  programming  interface  for  terrain  algo¬ 
rithms  such  as  mobility  factors  or  line  of  sight.  A  sec¬ 
ond  option  is  to  develop  correlated  data  from  the  same 
geospatial  data  sources  in  a  single  tool.  There  are  sev¬ 
eral  commercial  and  government- owned  tools  that  use 
a  common  set  of  raw  geospatial  feature  data,  elevation 
data,  and  imagery  to  generate  simulation  databases  in 
multiple  formats.  The  final  option  is  to  independently 
generate  correlated  databases  using  different  tools.  This 
option  may  introduce  correlation  errors  due  to  differ¬ 
ences  between  the  tools.  It  is  possible  to  manually  cor¬ 
relate  the  resulting  databases  using  common  reference 
points,  but  this  is  a  difficult  and  imprecise  process.  Re¬ 
gardless  of  the  option  used,  it  is  important  to  validate 
the  effects  of  terrain  data  on  the  scenario  during  the 
federation  test  phase.  Checking  the  validity  of  observed 
movement  rates,  line  of  sight  algorithms,  and  visual  rep¬ 
resentations  will  give  confidence  to  the  accuracy  and 


6 


2  SYSHUB  -  ENGINEERING  REQUIREMENTS  EOR  EEDERATED  SIMULATION 


correlation  of  environments  across  the  federated  mod¬ 
els. 

In  order  to  simplify  terrain  representation  and  minimize 
the  chances  for  negative  impacts  on  the  terrain  algo¬ 
rithms,  the  PEO  Soldier  project  has  decided  to  require 
each  federate  to  use  OneSAE’s  Environmental  Runtime 
Component  (ERG)  as  its  underlying  data  model.  When  a 
new  scenario  is  required,  there  is  no  need  to  separately 
generate  correlated  copies  of  the  terrain  database  in  dif¬ 
ferent  formats.  OneSAE,  IWARS,  and  COMBAT  XXI  all 
natively  reference  the  ERG  when  accessing  terrain  in¬ 
formation  during  the  run.  The  OneSAE  team  has  sup¬ 
ported  this  strategy  by  providing  C++  wrappers  for  the 
Java-based  ERG. 


2.3  Entity  Representation 

In  a  discrete  event  simulation,  entities  interact  with 
each  other  and  their  environment  so  that  the  system 
changes  over  time.  A  simulation’s  state  as  a  ‘‘collection 
of  variables  necessary  to  describe  a  system  at  a  par¬ 
ticular  time,  relative  to  the  objectives  of  a  study  (Law, 
2007).”  In  this  light,  the  state  of  an  entity  is  the  collec¬ 
tive  state  of  each  of  its  attributes.  Given  the  environ¬ 
ment,  interaction  with  other  entities  or  changes  in  other 
entities  that  influence  it,  changed  attributes  represent  a 
changed  state.  The  challenge  within  the  federation  is 
timely  and  consistent  application  of  each  entity’s  state 
throughout. 

In  a  federation,  each  supporting  federate  will  likely  use 
a  different  level  of  detail  for  the  representation  of  each 
entity.  Some  models  will  require  very  detailed  represen¬ 
tations  of  their  entities  to  support  detailed  calculations 
with  respect  to  that  entity’s  interaction  with  its  environ¬ 
ment  and  other  entities.  Other  simulations  may  have 
a  much  more  abstract  representation  with  much  less 
detail.  The  federation  design  must  account  for  these 
differences.  In  addition,  an  entity  may  have  a  combi¬ 
nation  of  static  and  dynamic  attributes.  The  static  at¬ 
tributes  are  set  at  simulation  initialization  and  do  not 
change  over  time.  The  type  of  weapon  a  particular  sol¬ 
dier  carries,  for  example,  is  often  a  static  attribute.  How¬ 
ever,  the  dynamic  attributes  do  change.  In  many  cases. 


these  changes  must  be  communicated  to  other  feder¬ 
ates  via  the  information  exchange  system.  Eor  example, 
a  soldier’s  location  and  health  status  will  change  over 
the  course  of  the  flght,  and  these  attributes  will  likely 
be  very  important  to  the  entities  represented  in  other 
federates. 

The  coordination  takes  place  in  three  steps  during  fed¬ 
eration  design.  Initially,  a  common  reference  descrip¬ 
tion  of  each  entity  is  identifled.  Eor  example,  a  particu¬ 
lar  type  of  combat  vehicle  may  be  described  by  a  fairly 
detailed  document  outlining  its  capabilities.  The  sec¬ 
ond  step  is  for  each  federate  to,  as  faithfully  as  possi¬ 
ble,  build  a  static  and  dynamic  representation  of  that 
combat  vehicle  given  the  constraints  of  its  internal  data 
structures.  Einally,  for  the  dynamic  attributes,  each  fed¬ 
erate  must  deflne  those  attributes  for  which  it  requires 
notiflcation  when  they  are  updated  in  another  simula¬ 
tion.  The  federation  designers  must  build  a  consoli¬ 
dated  list  of  those  attributes,  and  the  information  ex¬ 
changes  system  must  have  data  structures  for  repre¬ 
senting  changes  to  those  attributes  as  simulation  time 
advances. 

Within  the  PEO  Soldier  federation,  the  important  en¬ 
tities  to  be  represented  include  dismounted  soldiers, 
combat  vehicles,  and  unmanned  aircraft.  The  Military 
Scenario  Deflnition  Language  (MSDL)  is  used  to  deflne 
the  units  and  entities  that  will  participate  in  the  bat¬ 
tle.  During  scenario  development,  the  unit  composi¬ 
tion  and  entity  capabilities  are  deflned  by  authoritative 
TRADOC  sources  and  by  authoritative  AMSAA  weapons 
characteristics  and  data.  These  sources  provide  a  com¬ 
mon  shared  reference  for  the  supporting  combat  mod¬ 
els  to  build  a  scenario.  IWARS  represented  dismounted 
soldiers  in  great  detail,  with  very  abstract  representa¬ 
tions  of  vehicles  and  aircraft.  Eor  OneSAE  and  IWARS, 
the  aircraft  and  vehicles  were  represented  in  detail  while 
the  dismounted  soldiers  were  represented  in  less  detail 
than  for  IWARS.  Eor  the  dynamic  attributes,  the  MA- 
TREX  objects  IndividualCombatant,  GroundPIatform, 
and  AirPIatform  were  used  to  represent  these  entities 
(MATREX,  2008).  Each  federate  subscribed  to  these  in¬ 
teractions  and  updated  the  internal  states  of  these  enti¬ 
ties  as  required. 
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2.4  Models 

When  composing  models  in  a  federation,  model  valida¬ 
tion  requires  some  particular  considerations.  A  shal¬ 
low  application  of  interoperability  might  only  seek  to 
align  models  and  federates  by  converting  the  simula¬ 
tion’s  data  into  the  necessary  input  and  output  format 
specified  by  the  federates.  This  can  often  be  done  at  the 
programmer  level.  Support  for  interoperability  proto¬ 
cols  such  as  HLA  and  DIS  often  enable  new  federates  to 
be  ‘‘plugged  in”  with  little  or  no  programming  or  engi¬ 
neering.  The  danger  in  this  type  of  integration  is  that 
the  federated  model  may  not  be  designed  to  perform 
analysis  in  the  new  context.  Just  because  a  model  has 
been  validated  in  one  context  does  not  mean  that  it  can 
automatically  be  used  properly  in  a  new  context.  Com¬ 
posing  valid  federations  requires  some  additional  steps. 

The  subject  matter  experts  for  the  federated  model 
must  work  with  the  simulation  systems  engineers  to  val¬ 
idate  the  model  in  its  new  context.  While  model  valida¬ 
tion  is  a  complex  subject  beyond  the  scope  of  this  pa¬ 
per,  a  few  key  points  aid  the  discussion.  First,  it  is  as¬ 
sumed  that  the  federated  model  has  already  been  val¬ 
idated  in  some  context.  If  this  is  the  case,  the  model¬ 
ing  assumptions  from  the  original  validation  must  be 
checked  against  the  new  simulation  context  to  ensure 
that  this  new  context  does  not  invalidate  these  assump¬ 
tions  to  a  point  where  the  model  is  not  useful  in  the  new 
context.  Once  this  static  validation  is  complete,  further 
validation  can  take  place  during  the  federation  test  and 
evaluation  phase.  In  this  phase,  data  inputs  and  out¬ 
puts  from  the  model  are  checked  against  known  quan¬ 
tities  to  ensure  the  model  behaves  properly  in  the  new 
context.  Finally,  a  subject  matter  expert  in  the  domain 
to  be  modeled  can  visualize  or  check  model  runs  within 
the  new  context  to  give  “face  validity”  to  the  model  in  its 
new  context. 

An  example  of  these  considerations  is  the  federation’s 
handling  of  IWARS  soldiers  mounted  inside  OneSAF  ve¬ 
hicles.  Our  implementation  was  for  IWARS  to  mark  the 
soldiers  as  mounted  in  the  IndividualCombatant  infor¬ 
mation  exchange  and  move  the  locations  of  the  soldiers 
to  match  the  location  of  the  combat  vehicle.  In  each 
federate,  entities  were  not  permitted  to  directly  engage 
those  entities  that  were  marked  as  mounted  -  they  had 


to  engage  the  vehicle.  With  respect  to  interoperability 
of  the  data  structures,  this  approach  worked  perfectly 
well.  The  entities  moved  around  the  battlefield  and  dis¬ 
mounted  at  the  proper  location.  However,  the  new  con¬ 
text  violated  IWARS  internal  assumption  that  soldiers 
were  always  dismounted.  The  IWARS  simulation,  which 
owned  the  dismounts,  had  no  internal  model  for  assess¬ 
ing  damage  inside  a  vehicle.  If  a  vehicle  was  hit,  the  fed¬ 
eration  was  not  valid  because  it  would  have  not  been 
possible  to  assess  damage  against  its  occupants.  Fortu¬ 
nately,  OneSAF  did  have  an  internal  model  for  damage 
to  occupants  of  vehicles.  When  a  vehicle  was  hit,  One¬ 
SAF  ran  this  damage  model  against  all  of  its  occupants, 
regardless  of  which  simulation  owned  those  occupants. 
If  one  of  the  IWARS  soldiers  was  damaged,  OneSAF  sent 
a  DamageReport  interaction  to  IWARS  so  that  IWARS 
could  update  the  damage  state  of  its  mounted  entities. 
Another  validation  problem  was  that  these  mounted 
soldiers  were  still  able  to  acquire  enemy  targets  and 
build  situation  awareness,  even  though  they  were  com¬ 
pletely  enclosed  in  a  vehicle.  IWARS  had  to  turn  off 
the  target  acquisition  algorithm  for  these  mounted  sol¬ 
diers  because  they  could  not  see  outside  of  the  vehi¬ 
cles.  This  mount/ dismount  modeling  challenge  high¬ 
lights  the  complexities  that  can  arise  when  federating 
a  simulation  introduces  a  new  context  that  may  violate 
some  of  the  modeling  assumptions  of  the  federates  - 
in  this  case,  IWARS’  assumption  that  soldiers  would  al¬ 
ways  be  dismounted. 


2.5  Data  Collection 

Successful  analysis  requires  a  clear  definition  of  the 
questions  to  be  answered  and  an  understanding  of  the 
extent  to  which  the  questions  can  be  accurately  repre¬ 
sented  and  answered  by  the  tools  available  to  the  an¬ 
alyst.  There  are  two  primary  tasks  involved  in  moving 
from  questions  to  answers.  First,  the  question  must 
be  translated  to  a  form  representable  in  the  simulation, 
and  criteria  must  be  established  for  translating  the  re¬ 
sults  of  the  simulation  back  to  answers  to  the  original 
questions.  Second,  the  simulation  must  be  run  and 
enough  data  collected  to  answer  the  question  to  the  de¬ 
sired  level  of  confidence. 
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In  order  to  translate  the  questions  as  accurately  as  pos¬ 
sible  to  a  form  answerable  by  simulation,  the  analyst 
must  understand  the  modeling  assumptions  made  by 
the  designers  of  the  simulation.  A  completely  translated 
question  must  be  in  a  form  directly  answerable  by  sim¬ 
ulation.  It  should  be  phrased  in  terms  of  simulation  in¬ 
puts  and  outputs  only,  and  a  translation  must  be  de¬ 
fined  from  its  answers  to  answers  to  the  original  ques¬ 
tions. 

Once  translated,  the  question  establishes  a  requirement 
for  data  collection.  If  the  tools  available  to  the  ana¬ 
lyst  do  not  support  collection  of  the  data  required,  tools 
must  be  adapted  or  developed  to  meet  the  need  or  the 
scope  of  the  question  must  be  reduced  to  fit  the  avail¬ 
able  data. 

Current  tools  for  data  collection  tend  to  fall  into  two 
broad  categories.  The  first  consists  of  standalone  log¬ 
gers  which  record  raw  data  from  DIS,  HLA,  or  other  data 
interchange  systems.  The  other  consists  of  integrated 
data  collection  and  analysis  systems  that  record  infor¬ 
mation  at  a  level  of  abstraction  comparable  to  a  simula¬ 
tion’s  internal  object  model.  Integrated  data  collection 
systems  are  easier  to  use  as  long  as  they  provide  the  data 
required.  When  other  data  is  required,  it  is  often  possi¬ 
ble  to  construct  small  ad-hoc  tools  to  analyze  and  sum¬ 
marize  the  output  of  the  lower-level  loggers. 

In  addition  to  automated  tools,  human  observation  is 
a  valuable  tool  for  data  collection.  In  some  cases,  the 
most  practical  way  of  capturing  data  may  be  to  have  a 
human  expert  watch  or  participate  in  events  as  they  un¬ 
fold.  In  others,  human  psychological  or  physiological 
performance  may  be  an  important  part  of  the  experi¬ 
ment,  and  must  be  measured.  Thus  visualization  tools 
and  immersive  environments  are  also  an  important  part 
of  the  analyst’s  data- collection  toolset. 

Eor  the  PEO  Soldier  project,  three  different  approaches 
have  been  integrated  in  order  to  collect  the  required 
data  for  analysis.  Eirst,  the  internal  data  collection  sys¬ 
tems  for  IWARS,  OneSAE,  and  Combat  XXI  are  leveraged 
to  collect  data  such  as  target  acquisitions  and  weapons 
effects.  A  network  based  data  collection  tool  collects 
HLA  interactions  and  object  updates  in  order  to  assess 
metrics  such  as  soldier  locations  and  unit  attrition.  Ei- 
nally,  a  custom  data  collection  federate  was  developed 


to  monitor  and  record  the  situation  awareness  of  sol¬ 
diers  on  the  battlefield.  By  this  combination  of  tools, 
analysts  were  able  to  assess  the  necessary  performance 
metrics  and  effectiveness  metrics. 

2.6  Time  Management 

In  order  to  execute  successfully,  time  must  be  synchro¬ 
nized  across  the  federates  so  that  the  ordering  of  events 
and  interactions  mirrors  the  real  system.  Simulations 
are  synchronous,  so  the  federates  must  have  a  shared 
representation  of  time.  There  are  several  strategies  to 
achieve  this. 

The  first,  and  perhaps  the  simplest  and  most  common, 
is  to  required  the  federates  to  execute  in  real  time.  In 
this  case,  each  federate  keeps  an  internal  clock  synchro¬ 
nized  with  real  time  and  sends  messages  and  state  up¬ 
dates  at  the  time  they  occur.  The  federations  ordering  of 
events  is  preserved  with  respect  to  real  time.  A  modifi¬ 
cation  of  this  approach  is  to  have  each  federate  run  in  a 
multiple  of  real  time.  This  approach  requires  the  least 
modification  to  the  participating  federates.  However, 
the  repeatability  of  the  simulation  cannot  be  guaran¬ 
teed,  and  there  is  no  way  to  know  if  one  federate  speeds 
up  or  slows  down  with  respect  to  real  time.  There  is  a 
possibility  for  synchronization  errors  caused  by  a  fed¬ 
erate’s  ability  to  synchronize  its  internal  clock  with  real 
time. 

Another  approach  is  to  implement  some  form  of  time 
management  at  the  federation  level.  There  are  several 
approaches  to  this,  and  they  have  different  advantages 
and  disadvantages  (Taylor  et  al ,  2003)  (Carothers  et  al 
,  1997)(Eujimoto,  1998).  These  schemes  all  make  trade 
offs  with  respect  to  performance,  ease  of  implementa¬ 
tion,  and  repeatability.  The  High  Level  Architecture  im¬ 
plements  a  flexible  approach  that  allows  federates  with 
different  internal  time  advance  mechanisms  to  partici¬ 
pate  in  the  same  federation. 

Because  the  MATREX  Protocore  libraries  do  not  yet  im¬ 
plement  time  management  services  at  the  federation 
level,  the  PEO  Soldier  project  uses  real  time  synchro¬ 
nization.  Because  of  the  complexity  of  IWARS,  the  per¬ 
formance  penalty  for  real-time  execution  is  fairly  small. 
However,  it  is  not  possible  for  the  current  federation 
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to  guarantee  repeatability  in  the  time- ordering  of  its 
events. 

3  Systems  Engineering  Process  for 
the  Development  of  Federated 
Simulations 

The  requirement  for  a  systems  engineering  approach  to 
federation  development  stems  from  the  challenges  of 
representing  systems- of- systems  integration  in  a  sim¬ 
ulation  environment.  Typically,  simulations  exist  that 
represent  the  operation  of  some  of  the  subsystems. 
However,  when  these  subsystems  are  integrated  to  form 
a  new  capability,  a  new  simulation  model  is  often  use¬ 
ful  to  support  decision  making  and  optimization  with 
respect  to  that  capability.  The  federation  simulation 
developer  must  typically  rely  on  a  series  of  techniques 
from  other  disciplines  and  the  expertise  of  supporting 
developers  to  design  the  federation.  This  paper  out¬ 
lines  a  systems  engineering  approach  that  may  be  used 
to  guide  the  process  (Kewley  &  Tolk,  2009). 

The  real  challenge  of  simulation  development  is  to  en¬ 
sure  that  the  final  product  is  consistent  Avith  the  pur¬ 
poses  for  which  the  simulation  project  was  originally 
started.  It  should  support  analysis  of  different  strate¬ 
gies,  represented  as  simulation  inputs.  In  so  doing, 
there  must  be  a  mechanism  for  tying  different  simula¬ 
tion  development  activities  to  the  requirements  for  cer¬ 
tain  system  functions  to  be  modeled  and  to  certain  out¬ 
puts  to  be  produced.  A  systems  engineering  approach 
to  simulation  development  ensures  that  these  ties  to  re¬ 
quirements  are  maintained  throughout  the  process. 

The  process  borrows  from  the  Model  Driven  Archi¬ 
tectures  (MDA)  approach  to  produce  models  of  the 
simulation  system  on  three  different  levels  — target¬ 
ing  three  different  sets  of  stakeholders  (Object  Manage¬ 
ment  Group,  2007).  Operational  level  activities  produce 
an  operational  description  of  the  system  to  be  simu¬ 
lated.  The  operational  products,  analogous  to  the  Com¬ 
putation  Independent  Model  of  MDA,  are  independent 
of  the  fact  that  a  simulation  model  is  being  built.  They 
consider  the  concerns  of  the  operational  stakeholders 


who  must  use  or  operate  the  system  as  it  functions  in 
the  real  world.  The  system  level  activities  focus  on  the 
simulation  architecture  as  a  whole.  These  products, 
analogous  to  the  Platform  Independent  Model  of  MDA, 
assign  simulation  functions  and  metrics  to  different 
simulation  models.  The  primary  stakeholder  for  sys¬ 
tem  level  activities  are  integration  engineers  and  man¬ 
agers  for  each  of  the  component  models.  The  techni¬ 
cal  level  activities  focus  on  the  detailed  development 
of  simulation  components  and  the  interfaces  between 
them.  These  products,  analogous  to  the  Platform  Spe¬ 
cific  Model  of  MDA,  provide  sufficient  detail  for  soft¬ 
ware  engineers  to  develop  code  that  will  interface  with 
the  overall  simulation  federation  to  provide  the  required 
results.  In  some  cases,  the  software  or  test  cases  may  be 
auto -generated  from  the  technical  specification. 

3. 1  Operational  View  Activities 

In  performing  the  operational  level  activities,  simula¬ 
tion  engineers  are  focused  on  the  problem  definition 
phase  of  the  systems  engineering  process  (Parnell  etal , 
2008).  Their  primary  goal  during  this  phase  is  to  gain  an 
understanding,  documented  as  a  combination  of  Uni¬ 
fied  Modeling  Language  (UML)  specifications  and  other 
diagrams,  of  the  system  to  be  modeled.  They  should  un¬ 
derstand  its  users,  its  functions,  and  the  value  derived 
from  the  operation  of  the  system  itself.  The  steps  in  Fig¬ 
ure  2  represent  the  steps  of  this  process. 

Identify  system  use-cases  Identify  how  the  system  is 
used  by  different  classes  of  users  to  perform  the 
function  for  which  it  was  designed.  This  results  in 
a  high  level  UML  use-case  model  for  the  system. 

Functionally  define  the  system  Use  the  use-case 

model  and  work  with  system  users  to  define  in  a 
hierarchy  the  functions  of  interest  for  the  system. 
This  results  in  a  functional  hierarchy  for  the 
system.  Figure  3  shows  this  for  the  ground  soldier 
command  and  control  system. 

Identify  stakeholders  Identify  stakeholders  for  the  sys¬ 
tem.  These  are  not  only  users,  but  also  sys¬ 
tem  owners,  system  developers,  and  the  client  for 
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Eigure  2:  Operational  view  activities 


bdd  [Package]  Functional  Analysis[  g  GSS  Functional  Analysis  |J 


Eigure  3:  Eunctional  hierarchy  for  ground  soldier  command  and  control  system. 
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which  the  simulation  study  is  being  performed. 
Ensure  the  modeling  detail  captures  enough  infor¬ 
mation  to  answer  the  question  at  hand  without  in¬ 
corporating  so  much  detail  that  simulation  devel¬ 
opment  becomes  overly  difficult,  expensive,  and 
time  consuming. 

Elicit  stakeholder  concerns  Using  any  combination  of 
interviews,  focus  groups,  and  surveys,  determine 
the  fundamental  concerns  and  values  of  the  stake¬ 
holders  identified  in  the  previous  steps. 

Determine  system  objectives  Based  on  the  functional 
analysis  and  stakeholder  concerns,  determine  the 
system  objectives  that  must  be  successfully  met  in 
order  to  deliver  value  back  to  the  stakeholders. 

Define  value  measures  Once  the  objectives  have  been 
identified,  determine  value  measures  that  can  be 
used  to  see  if  the  system  has  indeed  met  those  ob¬ 
jectives.  The  simulation  system,  once  developed, 
must  be  able  to  estimate  system  performance  in 
terms  of  these  objectives  so  that  the  relative  perfor¬ 
mance  of  different  alternatives  can  be  determined. 
The  results  of  this  phase  may  be  represented  as  a 
value  hierarchy  specified  as  a  UML  class  diagram 
where  each  value  measure  is  a  component  of  an 
individual  objective,  and  individual  objectives  are 
components  of  the  overall  system  objective.  It  is 
also  helpful  to  specify  the  range  of  possible  values, 
from  least  desirable  to  most  desirable,  for  each  per¬ 
formance  measure  (Parnell  et  al  ,  2008).  Figure 

4  shows  the  value  hierarchy  for  a  ground  soldier 
command  and  control  system. 

Build  system  value  function  A  simple  value  hierarchy 
is  not  sufficient  for  direct  comparison  between  al¬ 
ternatives.  The  development  team  must  return  to 
the  stakeholders  and  determine  the  value  curves 
and  weights  for  each  performance  measure,  tak¬ 
ing  into  consideration  the  importance  and  overall 
variability  of  each  measure  (Parnell  et  al  ,  2008). 
This  results  in  a  value  function  that  translates  a 
set  of  performance  scores  for  each  alternative  into 
an  overall  value  score  that  represents  the  value  of 
that  alternative  to  the  system  stakeholders.  Figure 

5  shows  the  importance,  variability,  and  associated 


swing  weights  of  each  of  the  value  measures  for  the 
ground  soldier  command  and  control  system. 

Construct  operational  scenarios  Once  the  system,  its 
functions,  and  its  values  have  been  defined,  the 
simulation  study  team  must  also  define  the  sce¬ 
nario  that  represents  the  context  for  evaluation 
of  system  performance.  In  a  military  simula¬ 
tion,  this  represents  details  such  as  terrain  and 
weather,  forces  in  the  engagement,  supporting 
friendly  forces,  and  full  definitions  of  the  enti¬ 
ties  in  the  simulation.  The  scenario  definition 
describes  the  mission,  forces  involved,  and  roles 
of  the  simulated  entities.  In  a  military  context, 
the  Military  Scenario  Definition  Fanguage  is  an 
excellent  standard  for  this  representation  (SISO, 
2008).  Figures  6  shows  the  MSDF  representation 
of  the  platoon-level  scenario  used  for  the  PEO  Sol¬ 
dier  project.  This  is  a  platoon-sized  operation  de¬ 
rived  from  the  TRADOC  Multi-Fevel  Scenario  20  in 
which  a  Stryker  platoon  attacks  to  seize  a  series 
of  buildings  in  a  built  up  area.  The  primary  focus 
of  the  operation  is  the  first  squad  of  the  platoon 
that  will  secure  Objective  A.  Entity  definitions  are 
an  important  aspect  of  scenario  definition.  All  too 
often,  the  names  of  entities  can  lead  to  ambigu¬ 
ous  understandings  of  the  actual  capabilities  rep¬ 
resented.  Entity  definitions  should  be  as  specific 
as  possible  with  references  to  authoritative  sources 
that  provide  accurate  data  to  simulation  model¬ 
ers  who  must  represent  these  entities  in  their  re¬ 
spective  simulations.  Finally,  within  the  scenario, 
the  functions  performed  by  the  system  under  study 
should  be  defined  as  a  functional  flow  model  so 
that  simulated  events  can  be  synchronized  in  the 
proper  order.  This  model  can  be  represented  as  a 
UMF  activity  diagram.  The  functional  flow  model 
for  the  artillery  fires  request  function  of  the  ground 
soldier  command  and  control  system  is  shown  in 
Figure  8. 
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p»ckag«  Value  Analysis[  Value  Hiefafchy  ]J 


Eigure  4:  Ground  soldier  command  and  control  system  value  hierarchy. 
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^activity  Swing  weight  matrix  Swing  weight  matrix  ]J 


Most  important 


Very  important 


Important 


:  Increase  mission  execution  speed 
Time  in  minutes  to  complete  mission  objectives. 
Least  value:  120  minutes 
Mostvalue:  20minutes 
Vtfeglit:  100 


:  Maximize  TL  knowledge  of  enemy 
Percentage  of  acquired  enemy  known  by  TL. 
Least  value:  0% 

Mostvalue:  100 
\Afeigtit:  30 


:  Maximize  TL  knowledge  of  friendly 
Percentage  of  freindly  personnel  and  vehicles  in  scenario  known  by  TL. 
Least  value:  0% 

Mostvalue:  100 
WbiglTt:  30 


:  M  ini  miz  e  fr  lend  |y  casu  altie  s 
Percentage  of  original  friendly  force  alive  and 
healthy  at  end  of  mission. 

Least  value:  70% 

Mostvalue:  100% 

VVbiglTt:70 


:  Maximize  acquisition  of  enemy  targets 
Total  target  acquisitions  of  enemy  targets. 
Least  value:  0 
Mostvalue:  400 
lAfeight:  40 


:  Maximize  lethality  of  supporting  effects. 
Total  enemy  casualties  from  supporting  fires. 
Least  value:  0 
Most  value:  30 
lAteight:  15 


:  Maximize  PL  knowledge  of  enemy 
Percentage  of  acquired  enemy  known  ^  PL. 
Least  value:  0% 

Most  value:  100% 
lAfeight:  40 


:  Maximize  SL  knowledge  of  enemy 
Percentage  of  acquired  enemy  known  ^SL. 
Least  value:  0% 

Mostvalue:  100% 

Viteiglit:  15 


:  Maximize  PL  knowledge  of  friendly 
Percentage  of  freindly  personnel  and  vehicles  in  scenario 
known  by  PL. 

Least  value:  0% 

Mostvalue:  100% 

V\feight:40 


:  Minimize  acquisition  of  friendly  targets 
Total  target  acquisitions  of  friendly  targets. 
Least  value:  400 
Mostvalue:  0 
Weight:  40 


:  Maximize  SL  knowledge  of  friendly 
Percentage  of  freindly  personnel  and  vehicles  in  scenario  known  by  SL. 
Least  value:  0% 

Most  value:  100% 

Weight:  15 


:  Maximize  value  of  supporting  recon. 

Total  enemy  target  acquisitions  by  supporting  recon. 
Least  value:  0 
Mostvalue:  100 
Weight:  15 


:  Minimize  enemy  remaining  on  objective 
Percentage  of  original  enemyforce  alive  and  healthy 
on  objective  at  end  of  mission. 

Least  value:  100% 

Most  value:  0% 

VVbight:50 


:  Maximize  PL  message  completion 
Message  completion  rate  for  PL 
Least  value:  0% 

Most  value:  100% 

Wbight:  20 


:  Maximize  SL  message  completion 
Message  completion  rale  for  SL 
Least  value:  0% 
Mostvalue:  100% 

Wbight:  5 


:  Maximize  TL  message  completion 
Message  completion  rale  for  TL 
Least  value:  0% 
Mostvalue:  100% 

Wbight:  5 


Figure  5:  Swing  weight  matrix  used  to  build  system  value  function. 
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Eigure  6:  Military  Scenario  Definition  Language  representation  of  attack  scenario. 
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i(^<Plan> 

H  <ExecutiveSummary> 

<Ta3kOcganization>l/A  Co  1/1/A  Co  2/1/A  Co  3/1/A  Co  WPN3/1/A  Co  UAVl/A  Co  DS  Mortars 

A  Co</TaskOrganization> 

<F r lend lyFo tees >A  Company  attacks  at  200200JUN09  in  order  to  neutralize  all  enemy  south  of  Building  100,  White  Sands 
Missile  Range,  so  that  B  Company  can  pass  through  from  south  to  north  in  order  to  isolate  Building  100.  4/7 

(Stryker)  IN  attacks  at  200200JUN09  in  order  to  sezie  White  Sands  Missile  Range  and  secure  reported  CBRN  materials  in 
Buildings  100,  1400,  and  1401.</FriendlyForces> 

<EnemyFotces>A  platoon  sized  element  of  the  1st  BN,  1st  BDE,  10th  Infantry  Division  (light)  defends  on  our  objective 
.  Supporting  fires  from  other  platoons  to  the  north  and  west  will  threaten  our  maneuver  as  well.  Platoons  will  be 
arrayed  on  rooftops  and  dug  in  outside  of  buildings  to  deny  our  initial  assault.  As  we  acheive  success,  they  will 
likely  retreat  into  buildings  and  attempt  to  attrit  us  with  fires.  They  are  likely  to  wire  the  buildings  with 
explosives  and  lure  us  in  before  detonating  them.  Their  supporting  mortar  fires  will  attempt  to  disrupt  our  approach, 
but  they  will  be  less  effective  once  we  get  on  the  objective. </EnemyForces> 

<AttachmentsDetachments>UAVl/  A  Co  attached  to  1st  Platoon  for  this  miss ion. </AttachmentsDetachments> 

<Mission>lst  PLT  A  Co  attacks  at  200200  JUN  2009  in  order  to  neutralize  enemy  forces  on  Obectives  A,B,C,  and  D  so 

that  B  Company  can  pass  through  out  position  unhindered  by  enemy  action  from  south  to  north  in  order  to  isolate  building 

100 .</Mission> 

<Intent>The  purpose  of  this  mission  is  to  secure  the  southern  flank  of  the  battalion  objective  at  Building  100  so 
that  B  Co  can  pass  through  our  position  from  south  to  north  in  order  to  clear  the  immediate  area  around  the  building 
while  1  platoon  provides  fire  support  and  isolation.  We  will  achieve  this  by  clearing  buildings  on  our  objective  one  at 
a  time  while  fires  isolate  each  building  from  surrounding  threat.  We  will  complete  the  mission  with  enemy  neutralized 
on  our  objective  so  that  they  cannot  threaten  the  movement  of  B  Co  as  they  pass  through  our  position.  We  will  enter  and 

clear  building  only  if  enemy  in  those  buildings  cannot  be  neutralized  with  fires .</Intent> 

R  <ConceptOfOpetation>This  is  a  four  phased  operation. 

'  During  phase  1,  approach  march,  we  will  move  mounted  from  the  breech  point  to  Support  by  fire  positions  SI  and  S2. 

During  phase  2,  Stryker  vehicles  and  weapons  squad  will  take  up  overwatch  positions  in  or  near  SBF  SI  and  SBF  S2. 
Assisted  by  reconnaissance  from  the  UAV,  we  will  put  overwhelming  direct  and  indirect  fires  on  Objectives  A  and  B, 
shifting  fires  to  Objectives  C  and  D  at  the  start  of  Phase  3. 

During  Phase  3,  we  will  neutralize  enemy  forces  on  Objectives  B,  A,  D,  and  C  in  that  order,  leapfrogging  squads  to 
each  objective  in  succession  while  indirect  fires  shift  west  to  isolate  out  maneuver. 

In  phase  4,  we  will  occupy  support  by  fire  positions  oriented  North  on  building  100  and  provide  supporting  fires  for 
B  Company's  movement  onto  their  objective,  building  100,  to  our  north.  No  high  explosive  fires  are  pemitted  on 
-building  100  due  to  potentially  dangerous  CBRN  materials  stored  thete.</ConceptOfOpetation> 

R  <TasksManeuver> 

Phase  1.  Move  in  bounding  overwatch  into  SBF  SI  (A  section)  and  SBF  S2  (B  Section) .  Dismount  the  platoon. 

Phase  2.  UAV  Recon  of  OBJ.  Section  A  and  WPNS  1,  provide  fires  on  OBJ  B.  Section  B  and  WPNS  2  provide  fires  on 

OBJ  A. 

Phase  3.  UAV  tecon  west  of  OBJ  C  and  D.  2nd  Sqd  Secure  OBJ  B,  occupy  SBF  Bl.  1st  Sqd  Secure  OBJ  A,  occupy  SBF 
Al.  3rd  Sqd  secure  OBJ  D,  occupy  SBF  Dl.  1st  Sqd  Shitf  to  SBF  A2.  2nd  Sqd  Secure  Obj  D,  occupy  SBF  Cl. 

Phase  4.  WPNS  Sqd  mount  B  section  and  move  to  ABF  El  to  isolate  BLDG  100.</TasksManeuver> 


Figure  7:  XML  representation  of  the  operations  order  in  military  scenario  definition  language. 


Figure  8:  Call  for  fire  functional  flow  model 
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3.2  Systems  View  Activities 


Once  the  operational  picture  is  well  understood  and 
documented,  it  is  time  for  the  high-level  systems  de¬ 
sign  of  the  federated  simulation.  The  design  steps  in 
this  phase  build  UML  specifications  of  the  simulation 
functions,  simulation  data  collection,  information  ex¬ 
changes,  and  environmental  data.  These  steps  result  in 
a  logical  allocation  of  functionality  and  information  ex¬ 
changes  that  derive  from  the  operational  requirements 
from  the  previous  step.  While  not  sufficient  for  writing 
code,  these  models  allow  simulation  engineers  and  soft¬ 
ware  engineers  from  the  participating  federates  to  allo¬ 
cate  high-level  tasks  and  work  packages  to  support  sim¬ 
ulation  development.  Eigure  9  represents  the  steps  of 
this  process. 


Select  participating  simulations  Once  the  required 
functionality  is  known,  the  simulation  engineers 
must  research  candidate  federates  for  inclusion 
in  the  federation.  Some  of  the  considerations 
for  selection  are  the  capability  to  model  desired 
phenomena,  ease  of  integration  with  the  other 
models,  and  difficulty  of  required  modifications. 


In  some  cases,  a  new  federate  must  be  developed 
in  order  to  model  some  aspects  of  the  system. 

Eor  the  PEO  Soldier  federation,  the  participating 
models  are  IWARS  for  the  detailed  representation 
of  dismounted  soldiers  and  a  choice  of  Combat  ™ 
or  OneSAE  for  representations  of  supporting  un¬ 
manned  aircraft,  vehicles,  fires,  and  less  detailed 
representations  of  OPEOR  soldiers.  The  BCMS 
federate  Organic  Communication  Service  (OCS) 
generates  spot  reports  based  on  detection  events, 
the  Message  Transceiver  Service  (MTS)  calculates 
propagation  of  radio  messages,  and  the  Situation 
Awareness  and  Display  (SANDS)  federate  manages 
the  local  operating  picture  of  each  federate  in  the 
simulation.  Einally,  a  fires  federate  and  command 
and  control  federate  will  have  to  be  developed  in 
order  to  implement  fires  decisions  and  maneuver 
decisions  based  upon  the  situation  awareness  of 
small  unit  leaders. 

Allocate  simulation  activities  to  specific  simulation  models 

Once  the  candidate  federates  are  selected,  mod¬ 
eling  functions  must  be  allocated  to  individual 
federates.  The  resulting  functional  allocation  takes 
the  functional  flow  diagram  from  the  operational 
level  and  allocates  specific  functions  to  federates 
using  swim  lanes  in  the  UML  activity  diagram. 

This  allocation  for  the  ground  soldier  command 
and  control  simulation  is  shoAvn  in  figures  10 
and  11.  In  a  similar  fashion,  Eigure  12  shows  the 
allocation  of  command  and  control  functions  to 
simulation  federates. 

Allocate  value  measures  to  specific  simulation  models 

In  a  manner  similar  to  the  allocation  of  functions, 
the  requirements  to  collect  necessary  performance 
data  should  be  allocated  to  federates  as  well.  In 
some  cases,  the  required  data  may  not  exist  in  any 
one  federate,  but  will  have  to  be  collected  from 
network  interaction  data  collected  by  loggers.  In 
the  case  of  the  PEO  Soldier  federation,  most  of  the 
required  data  was  available  within  the  network 
data  logger  used  to  support  the  experiment. 
However,  a  custom  data  logger  was  required  to 
capture  the  knowledge  level  of  friendly  forces  over 
the  course  of  the  simulation. 


17 


PEO  Soldier  Simulation  Road  Map  VI  -  Command  and  Control  Modeling 


Figure  9:  System  level  activities. 


Define  simulation  modeling  functional  requirements 

Once  the  modeling  functions  and  data  collection 
functions  have  been  determined,  the  simula¬ 
tion  functionality  requirements  may  be  formally 
specified  for  the  models.  These  requirements 
documents  may  be  used  to  support  contracting 
with  federate  developers  who  must  deliver  models 
with  the  required  functions. 

Determine  information  exchange  requirements  In 

order  for  the  federation  to  execute,  data  must  be 
exchanged  between  the  models.  These  require¬ 
ments  may  be  derived  from  the  activity  diagrams 
used  to  allocate  functions  to  individual  federates. 
Any  time  that  a  control  line  crosses  a  swimlane, 
there  is  typically  a  requirement  for  some  amount 
of  information  to  be  passed  in  order  to  support 
that  allocation. 

Define  logical  data  model  for  information  exchange 

As  information  exchange  requirements  are  identi¬ 
fied  in  the  previous  step,  engineers  must  formally 
specify  the  data  elements  required  to  support  that 
data  exchange.  These  data  requirements  can  often 


be  specified  in  a  UML  class  diagram.  This  is  a 
two-way  process.  It  may  be  more  efficient  to  delay 
this  formal  specification  until  the  information 
exchange  architecture  is  selected  in  the  technical 
view.  In  some  cases,  information  elements  from 
that  architecture  may  be  reverse  engineered  to 
provide  the  required  information  elements. 

Build  entity  source  data  In  addition  to  developing 
simulation  software,  the  team  must  also  consider 
the  entities  that  will  participate  in  the  scenario. 
In  some  cases,  these  entities  must  be  constructed 
from  a  significant  amount  of  data.  This  step  rep¬ 
resents  the  collection  of  accurate  and  appropriate 
source  data  for  the  entities  in  the  scenario. 

Build  environmental  source  data  In  addition  to  enti¬ 
ties,  the  environment  must  be  considered  as  well. 
This  step  represents  the  collection  of  source  data 
necessary  to  appropriately  represent  the  environ¬ 
ment  in  the  different  federates.  The  environmen¬ 
tal  representation  may  not  be  the  same  for  all  fed¬ 
erates.  However,  using  the  same  source  data  will 
lead  to  correlated  representations  across  the  mod- 
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els.  Eor  the  PEO  Soldier  federation,  a  terrain  box  at 
White  Sands,  New  Mexico  was  used.  A  collection  of 
geospatial  elevation  data,  imagery,  and  shape  files 
was  compiled  to  support  terrain  data  generation 
using  a  commercial  tool. 
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Figure  10:  Allocation  of  request  fires  functions  to  simulation  federates,  represented  as  vertical  swim  lanes  (see 
continuation  in  Figure  11). 
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Eigure  11:  Allocation  of  request  fires  functions  to  simulation  federates,  represented  as  vertical  swim  lanes  (contin¬ 
ued  from  Eigure  10). 
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Figure  12:  Allocation  of  command  and  control  functions  to  simulation  federates. 
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3.3  Technical  View  Activities 

Once  the  system  has  been  designed  and  data  has  been 
collected,  it  is  still  necessary  to  do  system  development 
for  all  of  the  participating  federates  and  for  the  overall 
federation  integration  architecture.  These  are  all  tech¬ 
nical  level  activities  that  look  to  provide  software  engi¬ 
neers  and  programmers  sufficient  information  that  will 
allow  them  to  write  code  and  deliver  working  federates 
within  the  overall  specification.  Figure  13  shows  a  dia¬ 
gram  of  the  technical  level  activities  and  products. 

Select  information  exchange  technical  architecture 

The  simulation  must  exchange  information  across 
an  architecture  designed  for  this  purpose.  Simu¬ 
lation  standards  such  as  Distributed  Interactive 
Simulation  (DIS)  or  the  High  Level  Architecture 
(HLA)  are  possible  choices.  Another  possibility 
is  to  use  service  oriented  architectures,  based  on 
web  standards,  designed  to  support  business  or 
industrial  systems.  For  the  PEO  Soldier  federation, 
the  MATREX  High  Level  Architecture  has  been 
selected. 

Develop  information  exchange  data  model  The  infor¬ 
mation  exchange  data  model  must  be  specified 
and  represented  in  technical  format  selected  in  the 
previous  step.  In  the  case  of  HLA,  this  specifica¬ 
tion  will  be  a  federation  object  model  (EOM).  A 
web  services  architecture  would  require  extensi¬ 
ble  markup  language  (XML)  representations  of  the 
data.  Eor  the  PEO  Soldier  federation,  the  MATREX 
EOM  version  4.1  has  been  selected.  This  object 
model  contains  all  of  the  necessary  objects  and  in¬ 
teractions  necessary  to  execute  the  command  and 
control  activities  identified  in  the  systems  view 
Once  the  information  exchange  data  model  is  de¬ 
veloped,  a  UML  sequence  diagram  can  be  used  to 
translate  simulation  functions  into  sequence  dia¬ 
grams  that  explicitly  show  the  communications  be¬ 
tween  federates  and  the  simulation  functions  per¬ 
formed  by  each.  Eigures  14  through  18  show  UML 
sequence  diagrams  to  support  the  fires  and  com¬ 
mand  and  control  architectures  identified  in  the 
systems  view 


Specify  simulation  models  Required  simulation  func¬ 
tions  were  determined  as  a  systems  level  activity 
Now  these  function  must  be  specified  using  the 
language  and  format  of  the  information  exchange 
architecture.  Eor  example,  in  HLA,  certain  simula¬ 
tion  functions  could  be  started  upon  receipt  of  spe¬ 
cific  interactions  from  the  run-time  infrastructure 
(RTI).  In  a  web  services  integration,  these  functions 
could  be  represented  using  the  web  services  defini¬ 
tion  language  (WSDL). 

Build  entity  data  models  in  simulation  specific  formats 

In  this  step,  the  entity  data  collected  in  the  system 
level  activity  must  be  converted  into  input  formats 
that  can  be  read  by  the  participating  federates. 
These  representations  may  be  databases,  spread¬ 
sheets,  XML  files,  or  other  file  formats  required 
by  the  participating  simulations.  In  some  cases, 
supporting  tools  for  the  simulation  can  ease  this 
transition.  In  other  cases,  it  is  a  laborious  manual 
process  using  basic  editors.  Eor  the  PEO  Soldier 
federation,  an  XML  file  specified  the  entities  and 
types  required  by  each  simulation,  and  each  model 
built  the  necessary  data  files  required  to  simulate 
each  entity  in  their  respective  models. 

Build  data  collection  models  in  simulation  specific  formats 

In  this  step,  the  data  collection  requirements  de¬ 
termined  in  the  system  level  activity  must  be 
represented  as  output  data  from  simulation  fed¬ 
erates  or  from  data  loggers  tied  to  the  federation. 
Depending  upon  the  federate,  these  formats  may 
be  supported  by  standard  database  systems,  or 
they  may  simply  be  text  or  log  files  that  must  be 
processed.  The  developers  must  build  queries  or 
tools  that  collect  this  raw  data  and  summarize  it  as 
value  measures  from  the  value  model  built  in  the 
operational  level.  Eor  the  PEO  Soldier  federation, 
the  most  complicated  data  collection  requirement 
was  a  capability  to  record  the  situation  awareness 
state  of  each  friendly  entity  for  each  minute  of  the 
battle.  Eor  this  task,  a  custom  MATREX  federate 
was  created  to  query  SANDS  each  minute  on 
behalf  of  each  friendly  entity  It  wrote  a  data  file 
including  the  known  friendly  and  enemy  positions 
on  the  battlefield. 
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Figure  13:  Technical  level  activities. 


Build  terrain  data  models  in  simulation  specific  formats 

The  source  terrain  data  must  also  be  converted 
into  simulation  specific  formats.  In  many  cases 
commercial  tools  support  this  process  for  a  va¬ 
riety  of  formats.  In  other  cases,  the  terrain  data 
may  be  read  into  the  simulation  models  in  its 
existing  geospatial  format.  The  result  of  this  step 
is  correlated  representation  of  the  terrain  across 
the  federation.  For  the  PEO  Soldier  federation,  a 
commercial  tool  was  used  to  generate  correlated 
databases  in  the  OneSAF  ERG  format  and  in  an 
OpenElight  format  for  IWARS’  3 -dimensional 
viewer. 
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interaction  Oonrminicatel  ComTiunicate 


2:  IndiyidualOombatantUpdate^ 


3:  Prepare  Oonrminication 


6:  ComTunicat  ot  =  Corrmunic ation  =  Netw  orking 


7:  ReceKre  and  process  comnr  jt  ication 


3o  TT xinic ation  -  Networking  Producg  F  egion 

5:  Assess  conminic  ation  s  effects 


Eigure  14:  Communications  sequence  diagram.  This  diagram  shows  the  sequence  of  messages  required  for  semi- 
automated  forces  (SAE)  entities  in  IWARS,  OneSAE,  and  Combat  ™  to  send  communications  messages  to  each 
other.  The  MTS  communications  service  subscribes  to  the  platform  updates  of  all  entities  and  passes  them  along 
to  the  communications  effects  server.  In  this  way,  the  server  knows  the  locations,  terrain  types,  and  distances 
associated  with  point  to  point  communications.  SAE  entities  send  MATREX  communications  using  data  distri¬ 
bution  management  (DDM)  in  the  networking  producer  region.  The  MTS  subscribes  to  this  region,  but  the  SAE 
simulations  do  not.  The  MTS  will  assess  whether  the  message  was  delivered  to  its  receivers.  If  so,  it  will  publish 
that  message  using  DDM  in  the  networking  consumer  region.  The  SAE  simulations  will  subscribe  to  this  region 
and  deliver  the  communications  messages  to  the  associated  receiving  entity  for  processing. 
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iiite  ract  ion  Bui  Id  Situati  on  A  w  a  rene  ss  [  Build  Sit  uatio  n  A  w  ar  ones  s 


Figure  15:  Build  situation  awareness  sequence  diagram.  This  diagram  shows  the  sequence  of  messages  required 
for  SAF  entities  in  IWARS,  OneSAF,  and  Combat  ™  to  build  situation  awareness  for  enemy  forces.  When  a  friendly 
entity  on  the  battlefield  acquires  a  target,  it  publishes  a  MATREX  perception  message.  The  OCS  BCMS  federate 
publishes  a  salute  report  after  a  delay  period  that  would  be  required  for  the  entity  to  build  that  report.  This  report 
is  published  on  the  networking  producer  region,  assessed  by  the  MTS  for  delivery,  and  if  successful,  published 
on  the  networking  consumer  region.  The  SANDS  BCMS  federate  receives  salute  reports  and  updates  the  local 
operational  picture  (LOP)  for  the  receiving  entities.  In  addition,  SANDS  sends  periodic  spot  reports  up,  down,  and 
laterally  in  accordance  with  the  communications  hierarchy  for  friendly  units.  In  this  manner,  SANDS  maintains 
the  current  LOP  of  every  friendly  entity  and  makes  it  available  to  other  federates  via  MATREX  queries. 
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interaction  C2  Orders!  C2  Orders  ]J 


1:  RVM*\UAVFt/Route,  Networking  ProducerJ^gion 


Eigure  16:  Command  and  control  orders  sequence  diagram.  This  diagram  shows  the  series  of  messages  required 
to  issue  orders  to  IWARS,  OneSAE,  and  Combat™  in  order  to  execute  an  operations  order.  Each  command  is  first 
issued  using  DDM  on  the  networking  producer  region.  The  MTS  federates  determines  whether  the  message  can 
be  delivered.  If  so,  it  is  published  on  the  networking  consumer  region  for  implementation  by  the  receiving  unit. 
Unmanned  aircraft  orders  perform  reconnaissance  of  the  objective  area,  and  unit  movement  orders  move  SAE 
entities  to  the  objective  area. 
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interaction  MountDismount  [  ^  MountDismiunt 


Jf 


2:  Mount  NetworkingConsumerFaegion 


3:  Mount  NBtworkii|B|CDnsunierRegion 


5:  Move  Soldier  to  Mount  Point 


When  vehicle  is  within  20 
meters  of 

individualOintiatant 


7:  OroundHatfi  ri  riU|3date 


8:  lndwidualCombatantUt)dateMounted=TRJMountedOn  =  RatforrTlD  of  Vehicle 


9:  Dsable  entity  for  acquisition,  firing,  darrage  and  display 


kiiyoonsumerRegion 


3 


13:  MunitiopDetonation 


18:  asmountNetworkingConsunierRegion 


19:  DsmountNetwot  < 


16:  IndiviclualContatantltidate  Update  d; 


igOonsurrerRegion 
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Figure  17:  Mount- dismount  sequence  diagram.  This  diagram  shows  the  sequence  of  messages  required  for  an 
IWARS  soldier  to  mount  and  dismount  a  OneSAF  vehicle.  First,  the  command  and  control  federate  issues  a  MA- 
TREX  Mount  interaction  via  the  MTS  communications  service.  Assuming  both  the  soldier  and  vehicle  receive  the 
command,  they  both  move  to  the  mount  point.  Once  the  soldier  is  within  20  meters  of  the  mount  point,  both 
simulations  initiate  the  mounting  process.  IWARS  disables  the  acquisition,  engagement,  damage,  and  display  al¬ 
gorithms  for  the  soldier.  It  publishes  its  state  as  mounted  on  the  OneSAF  vehicle.  OneSAF  records  this  and  takes 
over  managing  the  damage  to  soldiers  mounted  on  its  vehicles.  As  the  OneSAF  vehicle  moves,  a  rocket  propelled 
grenade  engagement  hits  the  vehicle  in  which  the  soldier  is  mounted.  OneSAF  runs  its  damage  algorithm  for 
mounted  soldiers  and  publishes  the  results  in  a  MATREX  damage  report  message.  Upon  receiving  the  damage 
report,  IWARS  updates  the  damage  state  of  the  soldier  to  reflect  the  results  of  the  OneSAE  damage  calculation. 
Einally,  when  the  command  and  control  federate  issues  a  dismount  command,  OneSAE  stops  the  vehicle.  Once 
IWARS  detects  that  the  vehicle  is  stopped,  it  dismounts  the  entity,  resuming  internal  algorithms  for  acquisition, 
bring,  damage  and  display.  IWARS  then  publishes  updates  for  the  soldier  with  the  Mounted  held  set  to  EALSE. 
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Eigure  18:  OneSAE  fires  sequence  diagram.  This  diagram  shows  the  sequence  of  messages  required  for  OneSAE  to 
fire  mortar  rounds  in  response  to  fire  missions  generated  by  the  fires  federate.  The  fires  federate  replicates  the  role 
of  the  fire  direction  center  (EDC)  that  generates  the  fire  mission  and  the  fire  support  officer  (ESO)  who  clears  fires 
for  the  mission.  Eirst  the  EDC  generates  a  fire  mission  in  response  to  the  call  for  fire  message.  The  fire  mission  is 
passed  via  the  MTS  service  to  see  if  it  can  be  delivered  to  the  mortar  unit.  Once  delivered,  the  mortars  go  through 
the  process  of  laying  the  guns  on  the  target  and  await  a  final  fire  message.  In  parallel  with  the  process  of  laying 
the  guns,  the  ESO  conducts  clearance  of  fires  to  ensure  no  friendly  forces  are  in  the  vicinity  of  the  mission.  Once 
clearance  of  fires  is  complete,  the  ESO  sends  a  fire  message  to  the  guns  in  order  to  execute  the  mission.  The  guns 
fire,  and  a  munition  detonation  interaction  is  sent  to  IWARS  so  that  damage  can  be  calculated  against  dismounted 
targets  in  the  area. 
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3.4  System  Development  and  Testing 

Delivery  of  the  engineering  products  described  at  each 
level  will  give  system  developers  all  of  the  specifications 
they  need  to  build  software  components  that  deliver 
the  required  functionality  and  interface  with  the  feder¬ 
ation  architecture.  The  operational  level  will  give  them 
a  conceptual  context  for  integration.  The  system  level 
will  give  them  a  semantic  view  of  their  components  and 
an  understanding  of  the  overall  simulation  architecture. 
Finally  the  technical  products  will  specify  their  com¬ 
ponents  in  sufficient  detail  to  allow  them  to  interface 
with  the  selected  technical  infrastructure.  A  good  sys¬ 
tems  engineering  process  requires  stakeholders  from  all 
three  of  these  levels  for  the  to  work  together  in  a  coordi¬ 
nated  way. 

Despite  the  best  intentions  of  a  well  designed  architec¬ 
ture,  there  is  no  substitute  for  component  and  integra¬ 
tion  testing  to  ensure  all  of  the  pieces  work  as  adver¬ 
tised.  Component  tests  are  designed  around  individual 
components  and  their  interfaces.  They  typically  test  a 
discrete  function  by  replicating  the  inputs  from  the  fed¬ 
eration  and  reading  the  outputs  from  the  federate.  The 
MATREX  environment  supported  automatic  test  case 
generation  to  support  integration.  Larger  scale  inte¬ 
gration  tests  bring  together  a  number  of  federates  and 
test  the  ability  of  the  federation  to  model  system-level 
capabilities  and  to  collect  system-level  data.  Annex  C 
shows  a  sample  MATREX  test  case  generated  to  support 
the  Mount/ Dismount  functionality  for  the  federation. 
Simulation  developers  used  similar  test  cases  to  support 
communications,  situation  awareness,  fires,  and  com¬ 
mand  and  control  interactions.  These  test  cases  offered 
an  unambiguous  development  specification  for  devel¬ 
opers  that  minimized  miscommunication  and  reduced 
the  complexity  of  scheduled  integration  events. 

3.5  Advantages  of  a  Systems  Engineering 
Approach 

There  are  three  main  advantages  to  using  a  systems  en¬ 
gineering  approach  to  federated  simulation  develop¬ 
ment.  The  first  advantage  is  to  ensure  a  clear  line  of 
logic  from  operational  representations,  to  system  level 


federation  design,  to  coding  and  development.  A  sec¬ 
ond  advantage  is  the  separation  of  concerns  permitted 
by  modeling  the  system  on  three  different  levels.  Op¬ 
erational  experts  do  not  have  to  read  computer  code 
to  adjust  models  on  the  operational  level.  System  level 
experts  can  organize  and  specify  the  system  using  sys¬ 
tems  architecture  tools,  and  code  developers  can  work 
from  technical  level  specifications.  The  final  advantage 
is  that  all  of  the  systems  engineering  products  support 
the  engineering  manager  in  implementation  of  the  de¬ 
velopment  and  test  plan.  It  breaks  the  complex  feder¬ 
ation  into  discrete  pieces  of  functionality  that  can  be 
developed,  component  tested,  and  integration  tested  in 
order  to  manage  progress.  This  approach  has  helped 
during  implementation  of  the  ground  soldier  command 
and  control  federation,  saving  a  great  deal  of  develop¬ 
ment  time  and  effort  that  is  typically  spent  rectifying 
poorly  specified  interfaces  during  integration  tests. 

4  Command  and  Control  Federate 
Development 

The  systems  view  architecture  work  shown  in  Eigures 
10  through  12  reveals  a  requirement  for  a  command 
and  control  federate  to  perform  the  fires  and  maneu¬ 
ver  functions  identified  in  the  functional  analysis.  The 
West  Point  Operations  Research  Center  took  on  the  task 
of  developing  these  MATREX  federates  for  the  PEO  Sol¬ 
dier  federation.  The  center  developed  the  command 
and  control  federate  to  handle  the  maneuver  decisions 
and  the  fires  federate  to  handle  the  fires  decisions. 

The  critical  simulation  role  for  these  federates  is  to 
replicate  doctrinal  human  decisions  made  during  the 
course  of  the  battle.  These  decisions  require  informa¬ 
tion,  and  the  alternative  ground  soldier  command  and 
control  architectures  present  different  levels  of  situation 
awareness  to  the  leaders  making  these  decisions.  In  or¬ 
der  to  be  effective,  the  fires  federate  must  take  situa¬ 
tion  awareness  into  account  in  order  to  perform  fires 
decision  tasks  such  as  call  for  fire,  fires  approval  and 
clearance  of  fires.  The  command  and  control  federate 
must  bring  situation  awareness  into  the  maneuver  de¬ 
cisions  such  as  advancement  of  phases  and  selection  of 
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branches  in  the  maneuver  plan. 

4. 1  Fires  Federate 

Within  Army  doctrine,  there  are  four  key  functions  in 
the  fires  process.  Eirst,  an  observer  must  generate  a 
call  for  fire  based  upon  events  on  the  battlefield  (HQDA, 
1991).  If  applicable,  higher  units  will  approve  or  disap¬ 
prove  the  call  for  fire  based  upon  the  maneuver  and  fires 
plan.  Next,  the  commander  who  OAvns  the  battlespace 
must  clear  fires  within  that  space  to  ensure  no  friendly 
forces  are  in  the  area  (HQDA,  2002).  Once  fires  have 
been  cleared,  the  fire  support  officer  sends  a  fire  mis¬ 
sion  to  the  company  mortars  for  execution.  Although 
this  process  seems  pretty  straightforward,  it  is  very  dif¬ 
ficult  to  execute  at  the  speed  and  distances  required 
for  support  of  small  unit  operations.  Small  unit  train¬ 
ers  have  developed  a  series  of  forward  observer  bat¬ 
tle  drills  to  better  support  small  unit  infantry  opera¬ 
tions  with  indirect  fires  (Pinnell  &  Ivanoff,  2003).  Even 
with  these  battle  drills,  the  fog  of  the  battle  and  lim¬ 
ited  communications  channels  hamper  execution,  es¬ 
pecially  with  respect  to  situation  awareness.  It  is  possi¬ 
ble  for  a  ground  soldier  command  and  control  system  to 
augment  the  capability  of  a  small  unit  to  execute  these 
fires  (Copeland,  2007a). 

Eigures  10  and  11  show  the  high  level  design  require¬ 
ments  for  the  fires  federate.  The  fires  federate  is  re¬ 
quired  to  capture  the  differences  in  the  fires  process 
given  different  command  and  control  system  capabili¬ 
ties.  Eigure  19  shows  this  process  as  it  is  implemented 
at  platoon  level  within  the  fires  federate.  Consider  two 
differently  equipped  platoons.  The  Rapid  Eielding  Ini¬ 
tiative  (REI)  platoon  is  equipped  as  current  infantry  pla¬ 
toons  with  voice  radios  down  to  squad  level  used  for 
command  and  control.  The  Ground  Soldier  System 
(GSS)  platoon  is  equipped  with  the  Ground  Soldier  Sys¬ 
tem  command  and  control  capability  down  to  the  squad 
leader.  The  system  employs  the  following  capabilities: 

•  Automatic  passing  and  plotting  of  enemy  situation 
awareness  (SALUTE  reports) 

•  Automatic  passing  and  plotting  of  friendly  situa¬ 
tion  awareness  (Situation  reports) 


•  Generation  of  call  for  fire  messages  from  enemy 
situation  awareness  picture 

•  Clearance  of  fires  decision  support  based  upon  tar¬ 
get  location  and  munition  in  the  call  for  fire 

•  Eires  approval  decision  support  based  upon  clear¬ 
ance  of  fires  and  fire  support  plan 

•  Call  for  fire  forwarding  to  next  echelon  in  fires  pro¬ 
cess 

The  capabilities  enable  a  more  accurate  and  expedi¬ 
tious  fires  process  for  the  dismounted  platoon.  Eigures 
20  through  22  highlight  these  differences. 

The  technical  implementation  of  the  fires  federate  re¬ 
quired  the  capture  of  data  related  to  the  fires  process. 
The  West  Point  development  team  implemented  this 
data  in  the  extensible  markup  language  (XML).  The  key 
reference  data  elements  and  task  organization  elements 
for  the  mission  are  as  follows: 

Call  for  fire  equipment  These  are  the  capabilities  of 
the  equipment  used  by  a  dismounted  soldier  to  call 
for  fire.  These  capabilities  relate  to  the  time  re¬ 
quired  to  request,  receive  and  understand  enemy 
situation  awareness  and  the  time  required  to  gen¬ 
erate  and  send  a  call  for  fire  mission. 

Fires  approval  equipment  These  are  the  capabilities  of 
the  equipment  used  by  a  dismounted  soldier  to  ap¬ 
prove  fires. 

Fire  support  equipment  These  are  the  capabilities  of 
the  equipment  used  by  the  fire  support  officer  to 
approve  fires  and  generate  a  fire  mission. 

Battlefield  area  This  is  a  specific  region  of  the  battle¬ 
field  within  which  certain  fires  planning  factors 
and  priorities  apply. 

Attack  guidance  matrix  This  matrix  identifies  the 
types  of  targets  to  be  engaged  by  direct  fire  in 
priority.  Each  target  is  considered  a  cluster  of 
targets  within  a  certain  distance  of  each  other.  Eor 
example,  in  order  to  prevent  fires  at  individual 
enemy  dismounts,  the  fire  support  planner  may 
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Figure  19:  The  fires  process  as  modeled  by  the  Fires  Federate. 


32 


4  COMMAND  AND  CONTROL  FEDERATE  DEVELOPMENT 


Elapsed  Sim  Time:  00:00;03;17 


BLUFOR 


File  Edit  View  Manage  Exercise  Contiol  Checkpoint  lools  Window  Help 

&  ID  n  _ II  H  d*  ^  fH  A  O  +  • 

I  2.  Squad  leader  neoeives  SALUTE  report 

RFI  SL  will  plot  GSS  SL  will  receive 
SALUTE  report  on  digital  SALUTE  reports 
map.  (60  sec)  relayed  from  ISR 

displayed  on  GSS  (1 
j  sec) 

3.  Squad  leader  clusters  detected 
enemy  to  build  potential  target 

RFI  SL  manually  GSS  SL  selects  from 

selects  center  of  automatically 

mass  and  records  generated  clusters 

grid  (60  sec)  (10sec) 

4.  Squad  leader  uses  fires  support 
plan  to  build  mortar  call  for  fire 

RFI  SL  records  GSS  SL  builds  digital 

CFFdataon  report.  (15  sec) 

template  (30  sec) 


5.  Squad  leader  clears  fires  within  squad 

by  ensuring  no  squad  members  are  within 
danger  distance  for  requested  munition 

RFI  SL  estimates  GSS  system  plots  safe 
safe  distance  on  distance  on  display.  SL 
map  and  visually  veriTies  icons  are  not  within 
estimates  squad  this  distance.  (5  sec) 

locations  (30  sec) 


I  AItttS  I 


UAV 


position 


to  platoon  leader 

RFI  SL  sends  GSS  SL  sends  digital 

voice  message  message  (5  sec) 

(60  sec)  -=33 - - 


m 


Eigure  20:  Squad  leader  calls  for  fire.  This  diagram  shows  the  time  and  process  differences  between  an  REI- 
equipped  squad  leader  and  a  GSS- equipped  squad  leader  for  the  call  for  fire  task. 
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Eigure  21:  Platoon  leader  approves  fires.  This  diagram  shows  the  time  and  process  differences  between  an  REI- 
equipped  squad  leader  and  a  GSS- equipped  platoon  leader  for  the  approve  and  forward  call  for  fire  task. 
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Figure  22:  Fire  support  officer  generates  fire  mission.  This  diagram  shows  the  time  and  process  differences  that 
occur  when  the  fire  support  officer  receives  a  call  for  fire  from  an  RFI-equipped  platoon  as  opposed  to  a  GSS- 
equipped  platoon. 


list  five  enemy  dismounts  within  a  50  meter  radius 
of  each  other  as  a  target.  This  will  cause  units  to 
call  for  fire  only  on  groups  of  enemy  dismounts  of 
five  or  more.  Each  target  also  includes  a  planned 
munition,  number  of  rounds,  and  fuze  type,  along 
with  a  minimum  safe  distance  for  friendly  forces 
given  that  munition  and  fuze  type. 

Priorities  of  fire  This  is  a  list  of  friendly  units  in  order 
of  priority.  If  multiple  calls  for  fire  are  processing  at 
once,  those  from  higher  priority  units  will  be  pro¬ 
cessed  first. 

Clearance  of  fire  rules  The  first  element  of  these  rules 
is  a  time  threshold  for  the  age  of  friendly  situation 
reports.  If  the  situation  report  from  any  friendly 
unit  is  older  than  this  threshold,  clearance  of  fires 
will  not  be  granted  until  a  new  situation  report  is 
received  and  all  units  are  verified  as  outside  of  the 
minimum  safe  distance  for  the  mission.  In  addi¬ 
tion,  these  rules  allow  the  specification  of  robotic 
units,  such  as  unmanned  aircraft  systems,  which 


may  be  placed  at  risk.  Fires  will  be  cleared  even  if 
these  units  are  within  the  minimum  safe  distance 
for  the  mission. 

Call  for  fire  units  These  are  units  that  are  capable  of 
generating  a  call  for  fire,  such  as  a  squad  leader. 
Each  unit  will  is  further  defined  by  its  call  for  fire 
equipment,  the  attack  guidance  matrix  used  to 
generate  targets,  and  the  unit  to  which  the  call  for 
fire  message  will  be  sent. 

Call  for  fire  approval  units  These  are  units  that  per¬ 
form  the  role  of  approving  calls  for  fire.  They  will 
use  specific  fires  approval  equipment  in  this  role. 
They  will  consider  priorities  of  fire,  the  attack  guid¬ 
ance  matrix,  and  clearance  of  fires  rules  in  this  pro¬ 
cess.  They  will  forward  the  approval  to  other  units 
in  accordance  with  their  defined  relay  role. 

Fire  support  officers  These  are  leaders  that  accept 
calls  for  fire,  clear  and  approve  fires,  and  pass  fire 
missions  to  firing  units  for  execution. 
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Firing  units  These  are  mortar  and  artillery  firing  units 
that  have  certain  munitions  available  to  fire  at  tar¬ 
gets. 

Eigures  23  and  24  show  a  graphical  depiction  of  the  XML 
structure  of  the  data  required  by  the  fires  federate. 

The  West  Point  development  team  selected  the  Scala 
programming  language  for  implementation  of  the  fires 
federate  (Odersky  etal ,  2006).  The  key  factors  for  its  se¬ 
lection  are  its  support  for  functional  programming,  java 
interoperability,  polymorphism,  multiple  inheritance, 
multiple  threads,  and  XML  processing.  The  fires  feder¬ 
ate  runs  as  a  Proto  core  MATREX  federate.  It  queries  the 
BCMS  SANDS  federate  for  situation  awareness  in  the  ex¬ 
ecution  of  the  fires  process.  In  this  manner,  the  resulting 
fires  are  based  upon  a  simulation  of  the  situation  aware¬ 
ness  and  fires  processing  capabilities  of  the  unit’s  com¬ 
mand  and  control  equipment. 
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Figure  23:  Fires  data  elements  used  by  the  Fires  Federate. 


,  [T]  CallForFireUnits  ;  CallForFireUnit 


Q  .  [H  CallForFireApprovers  :  CaKForFireApprover 


FireSupportOfficers  :  FireSupportOfficer 


(CT)  CalForFireUnlt 

m  Originator  :  CommunicationTarget 
m  CalForFreEquipment  :  IDREF 
m  CalForFireReceiver  :  CommunicationTarget 
m  AttackGuidanceMatrix  :  IDREF 

fcFI  Ca«=orFireApprower 

m  ApproverName  :  CommunicationTarget 
m  FiresApprovalEquipment  :  IDREF 
m  ClearFiresRuies  :  IDREF 
m  PrioritiesOIFireName  :  IDREF 
m  RelayRoie  :  MessageReiay 
m  AtkGuidanceMatrix  :  IDREF 

fcfl  FireSupportOfficer 

1  .  BD  FSOName  :  CommunicationTarget 
i  FSOEquipment  r  IDREF 
m  RresReiay  :  MessageReiay 
.g  [T]  AttackGuidanceMatrix  :  IDREF 
m  Priorities  !  IDREF 
m  FiresQueueSize  ;  posith/elnteger 
m  FinalClearanceAuthority  :  CommunicationTarget 


j  .  [T]  Firingunits  :  FiringUnit 


®  FiringUnit 

m  FiringUnitName  :  string 
.  (T)  FiringUnitCommTarget  :  CommunicationTarget 


,  [T]  Munitions  :  MunitionsEnum 


Figure  24:  Fire  units  and  roles  used  by  the  Fires  Federate. 
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4.2  Command  and  Control  Federate 

There  are  a  few  high-level  design  requirements  for  the 
command  and  control  federate,  as  illustrated  in  Eigure 
12.  Eirst,  it  must  base  phasing  and  branching  of  based 
upon  situation  awareness.  An  information  requirement 
can  be  thought  of  as  a  yes  or  no  question  about  the  tac¬ 
tical  scenario  using  a  leader’s  awareness  of  friendly  and 
enemy  forces.  The  operation  moves  to  next  maneuver 
phase  based  upon  satisfying  information  requirements. 
Different  branches  of  a  phase  are  selected  based  upon 
satisfying  information  requirements.  Second,  the  feder¬ 
ate  must  be  able  to  issue  commands  to  all  participating 
federates.  In  other  words,  a  movement  order  issued  by 
the  command  and  control  federate  is  exactly  the  same, 
regardless  of  whether  the  executing  squad  is  owned  by 
IWARS,  OneSAE,  or  Combat™.  This  requires  develop¬ 
ment  in  each  participating  simulation  to  respond  to 
these  commands. 

The  introduction  of  digital  battle  command  to  the 
dismounted  soldier  via  the  Land  Warrior  system  has 
greatly  increased  the  dismounted  leader’s  situation 
awareness  picture  and  ability  to  control  maneuver  of 
his  elements  (Copeland,  2007b).  The  Ground  Soldier 
System  (GSS)  looks  to  further  increase  these  capabili¬ 
ties  with  improved  hardware  and  integration  with  other 
forces.  If  a  GSS  soldier  has  better  situation  awareness 
than  an  REI  soldier,  this  will  lead  to  more  timely  and  cor¬ 
rect  maneuver  decisions. 

Eigure  25  represents  the  command  and  control  process 
for  the  scenario  executed  by  the  PEO  Soldier  federation. 
This  process  is  completely  dependent  upon  the  passing 
of  orders  and  messages  on  the  command  and  control 
network.  Eor  example,  the  platoon  leader  will  not  order 
the  dismounted  assault  of  the  OBJ  A  to  begin  until  he  is 
aware  that  Section  A  has  reached  SBE  Al.  He  will  only 
reach  this  awareness  if  Section  A  reports  its  location  via 
the  command  and  control  network.  In  other  words,  the 
sequencing  of  operations  is  based  upon  friendly  situa¬ 
tion  awareness.  He  issues  this  command  to  1st  Squad 
on  the  command  and  control  network.  Next,  the  pla¬ 
toon  leader  will  base  the  decision  to  use  Axis  North  or 
Axis  South  based  upon  the  presence  of  enemy  forces  in 
NAI 1.  The  only  asset  that  has  good  visibility  of  NAI 1  is 
HAVE  Therefore,  he  will  only  know  about  enemy  forces 


in  NAI  1  is  he  receives  a  SALUTE  report  via  the  com¬ 
mand  and  control  network.  In  this  case,  his  maneuver 
decision  is  based  upon  enemy  situation  awareness.  By 
this  design,  the  federation  models  command  and  con¬ 
trol  as  a  series  of  messages  passed  on  a  communications 
network  that  build  situation  awareness  and  order  exe¬ 
cution  of  tactical  tasks  based  on  that  awareness. 

The  technical  implementation  of  the  command  and 
control  federate  required  the  capture  of  data  related  to 
the  command  and  control  process.  The  West  Point  de¬ 
velopment  team  implemented  this  data  in  the  extensi¬ 
ble  markup  language  (XML).  The  key  reference  data  el¬ 
ements  and  task  organization  elements  for  the  mission 
are  as  follows: 

Information  requirement  All  decisions  made  by  the 
federate  are  based  upon  the  information  require¬ 
ment.  This  is  a  yes  or  no  question  about  the  tacti¬ 
cal  situation  that  can  be  answered  based  upon  the 
leaders  awareness  of  friendly  forces,  enemy  forces, 
and  the  terrain.  An  information  requirement  data 
structure  consists  of  an  identification  of  the  decid¬ 
ing  leader,  a  tactical  graphic  that  represents  an  area 
of  the  battlefield,  and  a  query  of  friendly  or  enemy 
forces  related  to  that  tactical  graphic. 

Proximity  requirement  This  data  structure  defines  a 
specific  area  of  the  battlefield  that  will  be  queried 
for  the  presence  of  friendly  or  enemy  forces.  It 
may  be  proximity  specification  with  a  point  and  a 
specific  radius,  or  a  containment  specification  that 
consists  of  a  polygon  in  which  forces  may  be  con¬ 
tained. 

Friendly  unit  requirement  There  are  three  ways  to 
query  situation  awareness  for  an  information  re¬ 
quirement.  The  friendly  unit  requirement  asks 
whether  a  certain  number  of  entities  from  a  spe¬ 
cific  unit  are  present  in  a  certain  area. 

Friendly  platform  requirement  This  requirement  asks 
whether  a  certain  friendly  platform  is  present  in  a 
certain  area. 

Enemy  platform  requirement  This  requirement  asks 
whether  a  certain  number  of  enemy  platforms  of 
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Figure  25:  Scenario  graphic  illustrating  command  and  control  federate  execution.  Immediately  upon  execution  of 
the  mission,  the  platoon  leader  orders  1st  squad  to  mount  vehicles  and  the  unmanned  aircraft  (UAVl)  to  conduct 
reconnaissance  of  the  objective.  The  platoon  waits  3  minutes  for  UAVl  to  get  to  the  objective  before  ordering 
Section  A,  consisting  of  2  Bradley  Fighting  Vehicles  (BFV),  to  move  along  Route  Blue  to  its  support  by  fire  position 
(SBF  Al).  Once  Section  A  reports  they  are  in  SBF  Al,  the  platoon  leader  orders  1st  Squad  to  dismount.  He  waits 
one  minute  and  orders  them  to  conduct  a  dismounted  assault  of  Objective  A  (OBI  A).  As  the  squad  reaches  OBI  A, 
there  are  two  possible  routes  around  the  building  in  the  objective  area.  The  default  route  is  Axis  North.  However, 
the  platoon  leader  would  like  to  avoid  contact  if  possible.  If  there  are  two  or  more  enemy  dismounts  in  Named 
Area  of  Interest  1  (NAI 1),  the  platoon  leader  will  order  first  squad  to  continue  the  attack  along  Axis  South. 
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a  certain  type  are  present  in  an  area  of  the  battle¬ 
field. 

Mission  A  mission  is  a  named  tactical  operation  that 
consists  of  one  or  more  phases. 

Phase  A  phase  is  a  numbered  and  named  component 
of  a  mission  that  consists  of  a  trigger  condition  and 
a  default  set  of  tactical  orders  to  be  executed  by 
units.  It  may  also  contain  a  series  of  branch  or¬ 
ders  to  be  executed  is  the  associated  information 
requirement  is  met. 

Phase  trigger  This  is  a  condition  that  must  be  met  in 
order  to  execute  a  phase.  A  phase  can  execute  im¬ 
mediately,  after  a  delay  in  seconds,  or  wait  until  an 
information  requirement  is  satisfied. 

FRAGO  This  is  a  fragmentary  order,  a  set  of  tactical 
tasks  to  be  executed  by  units.  The  orders  im¬ 
plemented  by  the  PEO  Soldier  federation  include 
movement,  mounting  and  dismounting  of  forces, 
a  unit  attack,  and  route  and  orbit  missions  for  un¬ 
manned  aircraft. 

Branch  A  branch  is  an  alternate  ERAGO  to  be  executed 
if  a  particular  information  requirement  is  satisfied. 
A  phase  can  contain  one  or  more  branches.  The 
branches  are  queried  on  order  of  priority.  If  the  in¬ 
formation  requirement  for  the  first  branch  is  met, 
its  ERAGO  will  be  executed.  If  not,  the  deciding 
leader  will  check  to  see  of  the  information  require¬ 
ment  for  the  second  branch  is  met.  This  contin¬ 
ues  for  all  branches.  If  the  information  require¬ 
ments  for  all  branches  are  not  satisfied,  the  de¬ 
ciding  leader  will  issue  the  default  ERAGO  for  that 
phase. 

Eigures  26  and  27  show  a  graphical  depiction  of  the  XML 
structure  of  the  data  required  by  the  command  and  con¬ 
trol  federate. 

The  West  Point  development  team  implemented  the 
command  and  control  federate  in  the  Scala  program¬ 
ming  language.  The  resulting  Protocore  MATREX  fed¬ 
erate  queried  the  BCMS  SANDS  federate  for  situation 


awareness  and  issued  tactical  orders  using  the  Com¬ 
mand  interaction  in  the  MATREX  EOM.  With  this  imple¬ 
mentation,  leaders  built  situation  awareness  in  the  MA¬ 
TREX  BCMS  architecture  ensuring  that  network  topolo¬ 
gies  and  communications  effects  are  considered  for 
each  entity.  In  addition,  leaders  issued  orders  across 
that  same  communications  network  based  upon  their 
own  situation  awareness.  The  resulting  federate  al¬ 
lowed  the  federation  to  capture  the  decision  making  de¬ 
lays  and  effects  that  are  introduced  by  different  levels  of 
situation  awareness. 
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m  DecidingEntity  :  string 


m  ProximityRequirement  :  TacticalGraphicProximity 


(ct)  InformationRequirement 


(cf)  TacticalGraphicProximity 

m  TacticalGraphicName 

:  string 

Hi 

m  Containment  : 

<None> 

m  TacticalGraphicReferenc...  :  TacticalGraphkRefererK... 

m  ProximityDistance  :  double 

m  Proximity 

m  FriendlyUnit 


m  UnitName  :  string 


m  NumberOfEntitiesRequired  :  int 
GO  IRType  CX3  FriendlyPlatform  *5  (T]  PlatformID  :  string 

m  ClassifyType  :  RecognizeTypesEnum 


m  EnemyPlatform 


m  NumberOfPlatformsRequ...  :  int 


Figure  26:  Information  requirement  data  elements  used  by  the  command  and  control  federate. 


m  MissionName  :  string 


m  Mission 


^  >|m  Phases 


m  PhaseNumber  :  int 
00  PhaseName  :  string 


m  PhaseTrigger  :  PhaseTrigger 


•  nil  Branches  :  Branch 


(ct)  PhaseTrigger 

OO  TriggerType  :  Trigger TypesEnum 
(Xl  DelayInSeconds  :  double 

m  InformationRequrement  :  AndInformationRequire.. 


m  DefaultOrders  :  FRAGO 


(S) FRAGO 


•6  1  .  m  TaskOrders  :  TaskOrder 


(ct)  TaskOrder 

m  MessageAddress  :  MessageAddress 
m  MoveOrder  :  Move 
m  MountOrder  :  Mount 
[T]  DismountOrder  :  Dismount 
00  UnitAttackOrder  :  UiitAttack 
m  RWAUAVFlyRouteOrder  ;  RWAUAVFlyRoute 
OO  RWAUAVOrbitOrder  :  RWAUAVOrbit 


(ct)  Branch 

m  InformationRequirement  :  AndInformationRequire.. 


m  Orders  :  FRAGO 


Figure  27:  Mission  data  elements  used  by  the  command  and  control  federate. 
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5  Illustrative  Results 

The  following  section  shows  some  illustrative  results 
that  could  be  obtained  using  the  PEO  Soldier  federa¬ 
tion.  Note  that  these  results  are  illustrative  and  shown 
as  a  technical  proof  of  principal  -  that  the  federation 
can  indeed  produce  the  data  required  to  show  an  effec¬ 
tiveness  difference  resulting  from  different  command 
and  control  systems.  They  were  obtained  using  notional 
and  unclassified  data  with  federates  that  have  not  been 
subjected  to  verification  and  validation.  These  results 
should  not  be  construed  as  evidence  that  one  command 
and  control  system  is  better  than  another. 

5. 1  Situation  Awareness  Illustrative  Results 

A  custom  federate  was  developed  to  record  the  situa¬ 
tion  awareness  picture  of  each  leader  on  the  battlefield. 
The  leader  of  interest  for  this  scenario  is  the  1st  squad 
leader.  The  unmanned  aircraft  reconnaissance  quickly 
identified  19  of  the  23  enemy  soldiers  in  the  objective 
area.  These  positions  were  quickly  plotted  by  the  un¬ 
manned  aircraft  operator  and  sent  over  the  communi¬ 
cations  network.  In  the  GSS  case,  these  positions  were 
almost  instantly  and  automatically  relayed  all  the  way 
down  to  the  squad  leader.  In  the  RFI  case,  the  manual 
transmission  of  SALUTE  reports  across  multiple  eche¬ 
lons  made  the  relay  of  this  many  positions  nearly  im¬ 
possible.  Instead,  friendly  forces  became  aware  of  en¬ 
emy  forces  upon  contact.  This  occurred  as  the  mounted 
forces  made  contact  during  the  approach  along  Route 
Blue  in  the  8th  to  10th  minutes  and  again  as  the  dis¬ 
mounted  assault  cleared  the  objective  from  the  12th  to 
the  16  minute.  Figure  28  shows  the  situation  awareness 
of  the  1st  squad  leader  for  each  case.  The  gap  between 
the  red  and  blue  lines  in  this  graph  shows  opportunities 
for  action  against  enemy  forces.  The  GSS  squad  leader 
has  several  minutes  to  call  for  fire,  plan  maneuver,  and 
move  to  a  position  of  advantage. 

5.2  Fires  Illustrative  Results 

Because  the  GSS  squad  leader,  becomes  aware  of  enemy 
forces  on  the  objective,  several  minutes  before  the  RFI 


Enemy  Dismounts  Known  by  Squad  Leader 

20 


-♦-RFI  -*-GSS 


Figure  28:  Comparison  of  enemy  situation  awareness 
for  1st  squad  leader  for  RFI  and  GSS  cases. 

squad  leader,  he  can  initiate  a  call  for  fire  much  more 
quickly.  In  addition,  the  GSS  equipped  force  clears  and 
approves  fires  much  more  quickly  than  the  RFI  force. 
For  this  reason,  the  GSS  equipped  squad  is  able  to  pre¬ 
pare  the  objective  with  fires  prior  to  contact.  In  the 
RFI  case,  the  friendly  force  cannot  generate  and  process 
fires  in  time  to  have  any  effect.  Friendly  forces  are  in 
contact  and  too  close  to  the  enemy  for  effective  fires  by 
the  time  the  fire  mission  reaches  the  mortars. 

5.3  Maneuver  Illustrative  Results 

In  the  RFI  case,  the  dismounted  force  did  not  become 
aware  of  enemy  forces  in  NAI 1  until  they  made  contact 
with  them,  resulting  in  an  ambush.  In  the  GSS  case,  the 
squad  leader  becomes  aware  of  the  enemy  force  well  be¬ 
fore  he  must  commit  his  dismounted  assault  along  Axis 
North  or  Axis  South.  Based  upon  his  maneuver  plan 
(Figure  25),  the  command  and  control  federate  issues 
a  FRAGO  to  1st  squad  to  continue  the  attack  along  Axis 
South.  This  results  in  a  much  more  advantageous  fire- 
fight  AA/ith  the  enemy  in  NAI  1,  as  shown  in  Figure  29. 

5.4  Illustrative  System  Effectiveness 

While  situation  awareness  and  the  ability  to  impact  fire 
and  maneuver  are  important  factors,  mission  level  re- 
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Figure  29:  This  figure  shows  alternate  routes  taken  by  forces  given  different  levels  of  situation  awareness.  In  the 
RFI  case  (top),  the  dismounts  are  not  aware  of  the  enemy  located  in  NAI 1,  and  they  stumble  into  an  ambush.  In 
the  GSS  case  (bottom),  improved  awareness  of  enemy  forces  allows  the  squad  leader  to  issue  a  FRAGO  moving  the 
dismounted  assault  to  Axis  South.  This  is  a  much  more  advantageous  engagement  into  the  flank  of  enemy  forces  . 
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suits  are  the  real  indicators  of  the  effectiveness  of  a  com¬ 
mand  and  control  system.  As  an  example,  the  num¬ 
ber  of  friendly  survivors  in  1st  squad  was  collected  for 
both  the  REI  case  and  the  GSS  case.  Eor  the  REI  case, 
the  friendly  force  had  an  average  of  4.3  survivors  with  a 
standard  deviation  of  2.08.  Eor  the  GSS  case,  1st  squad 
had  an  average  of  7.3  survivors  with  a  standard  devia¬ 
tion  of  4.04.  Eor  this  particular  experiment,  the  results 
were  not  statistically  significant. 

Most  importantly,  this  illustrative  analysis  shows  the  ca¬ 
pability  of  the  PEO  Soldier  federation  to  assess  the  im¬ 
pact  of  the  GSS  on  the  fight.  It  led  to  improved  situa¬ 
tion  awareness  about  the  enemy  force.  This  allowed  the 
squad  leader  to  call  for  fire  and  adjust  maneuver  in  a 
way  that  was  not  possible  with  the  REI  case.  The  federa¬ 
tion  was  also  able  to  capture  effectiveness  metrics  such 
as  friendly  and  enemy  casualties  during  the  fight. 
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6  Planning  for  Academic  Year  2009- 
2010  Work 

Based  on  the  previous  work,  the  road  ahead  through 
May  2010  calls  for  continued  effort  in  contributing  to 
the  development  of  the  federation  so  that  it  can  be  used 
in  an  analysis  role  to  assess  planned  soldier  command 
and  control  systems.  This  capability  would  allow  PEO 
Soldier  and  Marine  Corps  Systems  Command  to  assess 
the  impacts  of  soldier  equipment  alternatives  on  unit 
outcomes. 

West  Point  will  continue  to  lead  the  modeling  and  anal¬ 
ysis  team  to  perform  the  following  three  tasks  for  the 
upcoming  year.  A  detailed  breakdown  of  tasks  is  shown 
in  ANNEX  D. 

•  Provide  analysis  support  to  the  XM-25  counter¬ 
defilade  target  engagement  system.  This  support 
will  include  analysis  support  for  validation  of  the 
basis  of  issue  of  the  XM-25.  Additionally,  it  will  in¬ 
clude  the  integration  of  America’s  Army  software 
with  OneSAE  so  that  virtual  prototypes  of  the  XM- 
25  can  be  used  in  an  analytical,  as  opposed  to 
game- only,  framework.  A  West  Point  cadet  cap¬ 
stone  team  will  support  this  effort. 

•  Provide  analysis  support  to  evaluate  the  effective¬ 
ness  of  automated  support  by  fire  position  selec¬ 
tion  in  a  dismounted  mission.  This  analysis  will 
inform  PM  Ground  Soldier  decisions  about  the  in¬ 
tegration  of  automated  terrain  analysis  capabilities 
into  the  Land  Warrior  System  and  Ground  Soldier 
System.  A  West  Point  cadet  capstone  team  will  sup¬ 
port  this  effort. 

•  Continue  to  do  federated  modeling  and  algorithm 
development  to  better  assess  the  impacts  of  soldier 
command  and  control  systems  on  mission  level 
performance.  This  includes  the  continued  im¬ 
provement  and  development  of  analysis  capabili¬ 
ties  with  respect  to  situation  awareness,  fires  and 
maneuver  decisions  based  upon  situation  aware¬ 
ness,  communications,  clearance  of  fires,  and  rules 
of  engagement. 
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Nomenclature 

AMSAA  Army  Materiel  Systems  Analysis  Activity 

ARL-SLAD  Army  Research  Lab  -  Survivability/ Lethality 
Analysis  Directorate 

B2P2  Brigade  and  Below  Propagation  and  Protocols 
BFV  Bradley  Fighting  Vehicle 

CERDEC  Communications -Electronics  Research,  De¬ 
velopment,  and  Engineering  Center 

COMBAT^^  Combined-Arms  Analysis  Tool  for  the  21st 
Century 

COMPOSER  Communications  Planner  for  Operational 
and  Simulation  Effects  with  Realism 

DDM  Data  Distribution  Management 

ERC  Environmental  Runtime  Component 

EDC  Eire  Direction  Center 

ERAGO  Eragmentary  Order 

ESO  Eire  Support  Officer 

GSS  Ground  Soldier  System 

HLA  High  Level  Architecture 

lEE  Identification  Eriend  or  Eoe 

IWARS  Infantry  Warrior  Simulation 

LOP  Local  Operational  Picture 

MATREX  Modeling  Architecture  for  Technology  Re¬ 
search  and  Experimentation 

MDA  Model  Driven  Architectures 

NAI  Named  Area  of  Interest 

OBI  Objective 

OneSAE  One  Semi-Automated  Eorces 

ORCEN  Operations  Research  Center  of  Excellence 

PEO  Program  Executive  Office 


RDECOM  Research  Development  and  Engineering 
Command 

REI  Rapid  Eielding  Initiative 
SAE  Semi-Automated  Eorces 
SBE  Support  by  Eire 

SMART  Simulation  and  Modeling  for  Acquisition  Re¬ 
quirements  and  Training 

STMS  Soldier  Tactical  Mission  System 

TRADOC  Training  and  Doctrine  Command 

UML  Unified  Modeling  Language 
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ANNEX  A  -  Development  Tasks  for  Academic  Year  2008-2009 


Task 

Assign  edTo 

Description 

Remarks 

Continued  HLA  Federation 

Development 

Combat  XXi 

Work'A'ith  other  mode  ling  te  ams  to 
continue  HLA  deve  lopme  nt  toward  a 
more  robust  representation  of 
communications,  command  and 
control,  lethality,  and  protection. 

Specifictasks  include; 

Build  MATREX  communications  support 

Build  MATREX  fire  s  archite  cture  support 

B u i  1  d  M AT R EX  situ ati o n  aw^ar e  n e  ss  sli p p o rt 

Build  behavioral  responses  to  M.ATREX  Soldier 

C2  interactions. 

Assess  federation  analysis 
ca|:i  abilities 

Combat  XXi 

Use  a  small  scenario  to  assess  the 

federation's  capability  to  assess  the 
ope  rational  value  of  different  soldier 
architectures  including  the  current 
soldier  system,  Land  Warrior,  and 
Ground  Soldier  System. 

Specifictasks  include: 

Update  interface  to  Protocore  4.1 

Update  support  for  ERC  and  MSDL  2.5 

Support  automatic  federation  start/stop 
Supporttime  management 

S  u  p  p  0  rt  e  ntity  own  e  r  sh  i  p  tr  an  sf e  r 

DocumentSOM  in  OMT 

Develop  data  collection  capabilities  to  support 
analysis. 

Communications  Modeling 

Combat  XXI 

Develop  a  capability  for  iW'ARS  to  run 

as  a  stand-alone  communications 

effe  cts  model. 

This  communications  model  must  work  in  a 

MATREX  architecture  by  integrating  with  the 

MAT  R  EX  M  e  ssage  T  r  an  sc  e  i  ve  r  S  e  r  vi  c  e  ( MTS ) .  It 
W'ill  receive  messages  from  MTS  and  use  the 
Brigade  and  Below,  Propagation  and  Protocol 
(B2P2)  model  to  determine  w-hether  message 
passed  from  sender  to  receiver. 

Develop  PEO  Soldier 

Scenarios 

Combat  XXI 

From  currently  approve dTRADOC 
scenario  s,  wo  r  k  '.vith  US  M A  an  d  P  EO  to 

e  >:tr act  small  scale  an aly si s  vi gn e tte  s 

from  within  those  scenarios.  These 

vignettes  should  address  recurringPEO 
Soldier  analysis  questions. 

Deliverable  swill  be  MSDL  representations  of 
these  scenarios  for  use  by  all  of  the  subordinate 
models.  Assignment  of  this  task  is  intended  to 
leverage  the  soldier  analysis  expertise  ofTR.AC- 

W'SMR. 

Soldier  Mode  ling  Team 

Combat  XXI 

Participate  in  hvo  annual  soldier 
modeling  team  conferences  to  discuss 
common  conce rnsw'ith  respectto 
development  processes,  be  haft.'iors. 
algorithms,  and  data. 

Figure  30:  COMBAT™ tasks  for  academic  year  2008-2009. 


Task 

Assign  edTo 

Description 

Remarks 

Continued  HLA 

Federation  Development 

iWARS 

Work  with  other  modeling  teams  to 
continue  HLA  development  to'ward  a 
more  robust  re  pre  se  ntation  of 
communications,  command  and 
control,  lethality,  and  protection. 

Specifictasks  include; 

Build  MATREX  communications  support 

Build  MATREX  fire  s  archite  cture  support 

Build  MAT  R  EX  situ  ati  o  n  awar  e  n  e  ss  su  p  p  o  rt 

Build  behavioral  responses  to  MAT  REX  Soldier 

C2  interactions. 

integrated  Casualt,' 

Estimation  Model 

IWARS 

Develop  a  methodolo^/  and  data 
requirementsforthe  use  of  ICEM 

resultsin  combat  simulations. 

AMSAA  cooperation  is  required  for  this  task. 
Run-time  issues  prevent  real-time  linkage  with 

ICEM. 

Rules  of  Engagement 

IWARS 

Develop  re  presentations  and  soldier 
behaviorsthat  capture  the  effects  of 

IFF  systems  and  rules  of  engagement 

in  combat  simulations. 

The  fidelib^^  of  these  representations  depends 
on  progress  in  the  underlying  science  from 
acrossthe  RS^D  commLinity. 

Asse  ss  federation 

analysis  capabilities 

IWARS 

Use  a  small  scenarioto  assess  the 

f  e  d  e  r  ati  0  n '  s  c  ap  ab  i  1  ity  to  asse  ss  th  e 
operational  value  of  different  soldier 
architecturesinckidingthe  current 
soldier  p/stem.  Land  Warrior,  and 
GroundSoldierSystem. 

Specifictasks  include; 

Update  interface  to  Protocore  4.1 

Update  SLipportfor  ERC  and  MSDL  2.5 

Support  automatic  federation  start/stop 
Supporttime  management 

Support  entity  ownership  transfer 

Document  SOM  in  OMT 

Develop  data  collection  capabilities  to  support 
analysis. 

Improve  STA  processfor 

soldier  sensors 

IWARS 

improve  representation  of  soldier 
sensorsand  the  search  and  target 
acquisition  process  within  combat 

simulations. 

Where  appropriate,  implement  existing 
methodologies  in  IWARS. 

Figure  31:  IWARS  development  tasks  for  academic  year  2008-2009 


Task 

Assign  edTo 

Description 

Remarks 

Continued  HLA 

Federation  Development 

OneSAF 

Work'A'ith  other  modeling  teams  to 
continue  HLA  development  tovyard  a 
more  robust  re  pre  se  ntation  of 
communications,  command  and 
control,  lethality,  and  protection. 

Specifictasks  include; 

Build  PvlATREX  communications  support 

Build  MATREX  fire  s  archite  cture  support 

Build  MAT  R  EX  situ  ati  o  n  awar  e  n  e  ss  su  p  p  o  rt 

Build  behavioral  responses  to  MAT  REX  Soldier 

C2  interactions. 

Asse  ssfe  deration 

analysis  capabilities 

OneSAF 

Use  a  small  scenarioto  assess  the 

f e  d  e  r  ati  0  n '  s  c  ap  ab  i  1  ity  to  asse  ss  th  e 
operational  value  of  different  soldier 
architecturesinckidingthe  current 
soldier  system.  Land  Warrior,  and 
Ground  Soldier  System. 

Specifictasks  include; 

Update  interface  to  Protocore  4.1 

Update  SLipportfor  ERC  and  MSDL  2.5 

Support  automatic  federation  start/ stop 
Supporttime  management 

Support  entity  ownership  transfer 

Document  SOM  in  OMT 

Develop  data  collection  capabilities  to  support 
analysis. 

Soldier  Pvlode  ling  Team 

OneSAF 

Participate  inbA'o  annual  soldier 
modelingteam  conferencesto 

discusscommon  concernswith 

respect  to  development  processes, 
be  ha'/iors,  algorithms,  and  data. 

Asse  ssFederation 

Analysis  Cap  abilities 

PEOSoldier 

Use  a  small  scenarioto  assess  the 

federation's  capability  to  assess  the 
operational  value  of  different  soldier 
architecturesinckidingthe  current 
soldier  ?|,‘'stem.  Land  Warrior,  and 
Ground  Soldier  System. 

Spe  cific  tasks  include  detaile  d  de  scriptions  of 
different  soldier  as  a  s-ystem 
architectures.  Provide  analysis  que stions that 
currently  ans^Aer  PEO  Soldier  decision 
challenge sw'ith  respectto  these  architectures. 

Pv’lap  soldier  capabilib,' 
gaps  to  modeling 

requirements 

PEOSoldier 

PEOSoldier  should  identify  and 
prioritize  the  soldier  capability  gaps 
they  are  addressing.  They  will  then 
work  with  the  Simulation  Road  Mapi 
team  to  map  those  gaps  to 
simulation  requirements  so  that 

simulation  resourcescan  be  directed 

atthe  issues  of  concernforthe  PEO. 

Figure  32:  OneSAF  and  PEO  soldier  tasks  for  academic  year  2008-2009 


Task 

Assigned  To 

Description 

Remarks 

Asse  ssFederation 

Analysis  Cap  abilities 

USMA 

Use  a  small  scenarioto  assess  the 

f  e  d  e  r  ati  0  n '  s  c  ap  ab  i  1  ity  to  asse  ss  th  e 
operational  value  of  different  soldier 
architectures  including  the  current 
soldier  system.  Land  Warrior,  and 
GroundSoldierSystem. 

Specific  tasks  include  orchestrating  input  data 
development  across  the  models,  conducting 
the  analysis  runs,  colle  cting  and  analyzing 
output  data,  ans'^ve ring  the  study  question, 
and  providing  feedback  about  model 
development  priorities  that  woLild  enhance 
the  analysis  capabilities  of  the  federation. 

Command  and  Control 

Modeling 

USMA 

Build  an  ability  for  reactive  command 

and  control  into  the  federation. 

These  be ha^nors  must  be  friendly, 
e  n e  my.  and  terrain  a^A'ar e . 

First  effort  will  beto  identify  soldier  C2 
beha^'iorsat  individual,  fire  team,  squad,  and 
platoon  level.  Then  develop  C2  inte ractions to 
be  used  in  the  FOMto  pass  these  behaviors 

intothe  models.  Once  each  model  has  built 

internal  response  sto  these  C2  behaviors, 
develop  C2  federates  that  pass  ordersto 
soldier  entities  based  on  updated  C2 
information  aboLit  friendly  forces,  enemy 
forces,  mission,  and  terrain. 

MDAfor  Federation 

Development 

VMASC 

Continue  to  assess  the  applicability 

of  Model  Driven  Architecture  sto  the 

federation  development  process. 

For  this  year,  place  particular  emphasis  on  the 
further  development  of  the 
MATREX/PROTOTCORE  e nvironme nt  in  order 
to  use  a  s'p'^stems  engineering  approach  to 
move  from  requirements,  to  s'ystem  selection, 

to  orchestration,  and  execution. 

Battle  Management 
Language  forSoldier  C2 

VMASC 

Support  development  of  soldier  C2 

architecture  with  Battle 

Management  Language  (BML) 
represe ntationsof  soldier  C2  tasks. 

Support  includes  data  definition  for  BML 
structure  sand  prototype  implementation  of 

command  and  control  federates  that  assess 

the  current  situation  and  issue  ordersto 

soldiersusing  BML. 

Asse  ss  federation 

analysis  capabilities 

VMASC 

Use  a  small  scenarioto  assess  the 

federation's  capability  to  assess  the 
operational  value  of  different  soldier 
architectures  including  the  current 
soldier  system.  Land  Warrior,  and 
GroundSoldierSystem. 

Specific  VMASC  task  will  be  to  focus  on  the 
federation's  handling  of  data  for  analysis.  How 
doesthe  analyst  configure  the  federation  to 
collectthe  appropriate  data  to  support  the 
an  aly  si  squestions  give  n  th  e  d  iff  e  r  e  nt  d  ata 

collection  instruments  on  the  federation  and 

within  the  individual  models. 

Federation  development 
engineering 

management  plan 

VMASC 

Develop  an  engineering 
management  plan  to  support  the 
fe  de  ration  deve  lopme  nt  tasks 
planned  for  academic  year  2008- 
2009. Support  execution  of  that  plan 

Wiith  assessments  of  on-time  and 

performance  criteriaduring 

execution. 

D  e  1  i  ve  ry  of  th  e  plan  wo  li  I  d  take  p  1  ac  e  to  war  d 
the  end  of  the  summer  to  support  planning  for 
nextyear's  effort. 

Figure  33:  USMA  and  VMASC  tasks  for  academic  year  2008-2009 
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ANNEX  C  -  Sample  MATREX  Test  Case  for  Mount/Dismount  Function 


ATC  Test:  IWARSMountDismount 
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Author 

Test  Case  Category 

ATC  Generated  Tue  Mar  31  15:21:57  EDT  2009 

ATC 

Purpose/Objective 

(Description  of  the  purpose/objective  for  this  test  case) 

This  test  case  tests  IWARS  capability  to  mount  and  entity  on  a  OneSAF  vehicle.  This  test  can  be 
executed  using  the  entitties  as  defined  by  the  MSDL  file  WhiteSandsAttack3.xml.  Specifically,  the 
dismounted  soldiers  "B/2/1/SAW"  and  "B/2/1/GRND"  will  mount  the  vehcle  "Stryker  PL  WM"  . 


The  chain  of  events  will  proceed  as  follows. 

1.  C2  Federate  issues  a  Mount  interaction  with  MountDismountCommand  set  to  "Mount" 

2.  IWARS  moves  soldiers  to  mount  point. 

3.  When  soldier  is  within  10  meters  of  the  vehicle,  IWARS  mounts  the  soldier. 

4.  The  soldier  cannot  perform  combat  functions  inside  the  vehicle,  so  IWARS  disables  the  soldier  for 
target  acquisition,  firing,  damage  (which  will  be  computed  by  OneSAF),  and  display.  However, 
IWARS  continues  to  update  the  StateVector  of  these  entities  to  match  the  StateVector  of  the  vehilce 
they  ride.  IWARS  continues  to  publish  IndividualCombatant  updates  based  on  this  StateVector. 

5.  IWARS  sends  a  IndividualCombatantUpdate  to  reflect  mounted  status  of  the  soldier  on  the 
designated  vehicle. 

6.  The  vehicle  begins  to  move. 

7.  The  vehicle  is  hit  by  an  RPG,  causing  OneSAF  to  assess  one  of  the  mounted  soldiers  as  a  K_Kill. 

8.  OneSAF  sends  a  DamageReport  for  the  mounted  soldier. 

9.  IWARS  updates  the  damage  status  of  the  entity  based  on  the  DamageReport. 

10.  The  C2  Federate  issues  a  Dismount  command. 

11.  The  vehicle  stops. 

12.  IWARS  soldier  dismounts  the  vehicle. 

13.  IWARS  reactivates  the  soldier  for  target  acquisition,  firing,  damage,  and  display. 

14.  IWARS  sends  an  IndividualCombatantUpdate  to  relfect  the  dismunted  status  of  the  soldier. 

System/Actor  Notes: 


Federate  Name 

Notes 

IWARS 

OneSAF* 

C2  Federate* 

*  indicates  played  by  ATC 


Sequence  Diagram 
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Entrance  Criteria 

(Conditions/products  required  in  order  to  support  the  execution  of  this  test) 

Successful 

(V) 

IWARS  ready  and  available 

RTI  software  ready  and  available 

ATC  test  case  ready  and  available 

[] 

# 


Setup  Steps 


Successful 


(Steps  needed  to  setup  the  conditions  of  the  test) 
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Notes: 

This  checks  to  be  sure  IWARS  is  registering  the  entities  B/2/1/SAW  and  B/2/1/GRND 


ATC  Event: 

Name  Send  Receive  Delay  MinWait  MaxWait  Dependencies 

RegisterlWARS  IWARS  OneSAF  0 _ 0 _ 60 _ - _ 


Parameter  Name  Validated  Value 

PlatformID  B/2/1/SAW 


Notes: 

This  checks  to  be  sure  IWARS  is  registering  the  entities  B/2/1/SAW  and  B/2/1/GRND 


ATC  Event: 

Name  Send  Receive  Delay  MinWait  MaxWait  Dependencies 

RegisterlWARS  IWARS  OneSAF  0  0  60  - 


Parameter  Name  Validated  Value 

PlatformID  B/2/1/GRND 


Notes: 

This  interaction  ensures  IWARS  is  sending  IndividualCombatant  updates  for  the  entities 
”B/2/l/SAW”  and  ’’B/2/1/GRND 


ATC  Event: 


Name  Send  Receive  Delay  MinWait  MaxWait  Dependencies 

UpdatelWARS  |  IWARS  OneSAF  0  0  20  ReSteriWARS 


Parameter  Name  Validated  Value 

PlatformID  B/2/1/SAW 


Notes: 

This  interaction  ensures  IWARS  is  sending  IndividualCombatant  updates  for  the  entities 
”B/2/l/SAW”  and  ’’B/2/I/GRND 


ATC  Event: 


Name  Send  Receive  Delay  MinWait  MaxWait  Dependencies 

UpdatelWARS  IWARS  OneSAF  0  0  20  R^SriWARS 


Parameter  Name  |  Validated  Value 

PlatformID  B/2/1/GRND 


Notes: 

Registers  the  vehicle  "Stryker  PL  WM"  for  discovery  by  IWARS. 


ATC  Event: 

_ Name _ Send  Receive  E 

RegisterOneSAF  OneSAF  IWARS  5 


Send  Receive  Delay  MinWait  MaxWait  Dependencies 

neSAF  IWARS  5  0  0 

UpdatelWARS 


6  ATC  Event: 
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Notes: 

Mount  command  from  Squad  Leader,  2/1/SQDLDR  to  B/2/1/SAW  and  B/2/1/GRND  to  mount  the 
vehicle  "Stryker  PL  WM".  This  should  initiate  movement  of  both  entities  to  the  mount  point.  When 
within  1  Om  of  the  vehcicle,  the  entities  should  be  mounted. 


ATC  Event: 


Name  Send  Receive  Delay  MinWait  MaxWait 

Mount  C2  Federate  IWARS  15  0  0 


Dependencies 

UpdateOneSAF 


Notes: 

Once  mounted,  IWARS  sends  an  IndividualCombatant  update  for  each  entity  with  Mounted=TRUE 
and  MountedOn=" Stryker  PL  WM".  At  this  time,  IWARS  should  also  disable  each  entity  for  target 
acquisition,  firing,  damage,  and  display.  However,  IWARS  continues  to  update  the  State  Vector  of 
these  entities  to  match  the  State  Vector  of  the  vehilce  they  ride.  IWARS  continues  to  publish 
IndividualCombatant  updates  based  on  this  State  Vector. 


ATC  Event: 


Name  Send  Receive  Delay  MinWait  MaxWait  Dependencies 

ICUpdateMounted  IWARS  OneSAF  0  0  300  Mount 


Parameter  Name 

Mounted 

MountedOn _ 

PlatformlD 


Validated  Value 

true 

Stryker  PL  WM 
B/2/1/SAW 


Notes: 

Once  mounted,  IWARS  sends  an  IndividualCombatant  update  for  each  entity  with  Mounted=TRUE 
and  MountedOn=" Stryker  PL  WM".  At  this  time,  IWARS  should  also  disable  each  entity  for  target 
acquisition,  firing,  damage,  and  display.  However,  IWARS  continues  to  update  the  State  Vector  of 
these  entities  to  match  the  State  Vector  of  the  vehilce  they  ride.  IWARS  continues  to  publish 
IndividualCombatant  updates  based  on  this  State  Vector. 


ATC  Event: 


Name  Send  Receive  Delay  MinWait  MaxWait  Dependencies 

ICUpdateMounted  IWARS  OneSAF  0 _ 0 _ 300 _ Mount _ 


Parameter  Name 

Mounted _ 

MountedOn _ 

PlatformlD 


Validated  Value 

true _ 

Stryker  PL  WM 
B/2/1/GRND 


Notes: 

Based  on  an  RPG  hit,  OneSAF  comutes  damage  to  one  of  the  mounted  entities  and  passes  the  report 
so  that  IWARS  can  update  its  status. 


10  ATC  Event: 


Send  Receive  Delay  MinWait  MaxWait  Dependencies 

DamageReport  I  OneSAF  IWARS  5  0  0 


Notes: 

Once  the  damage  interaction  is  received  by  IWARS,  IWARS  updates  the  status  of  B/2/1/SAW  to  K- 
Kill 

ATC  Event: 

^^en^_  ^R^ceiv^  ^Dela^  ^linWai^  ^laxWai^  ^De^endencie^ 

ICUpdateKilled  IWARS  OneSAF  0 _ 0 _ 30 _ DamageReport 


Parameter  Name  Validated  Value 

DamageState  K  Kill 

PlatformlD  B/2/1/SAW 
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Notes: 

OneSAF  vehcile  updates  its  position  to  arrive  at  the  dismount  point. 


12  ATC  Event: _ _ _ ^ _ _ _ 

Name  Send  Receive  Delay  MinWait  MaxWait  |  Dependenci^ 

UpdateOneeSAFVehicleArrives  OneSAF  IWARS  20  \0  \0 


Notes: 

C2  Federate  issues  dismount  command  to  dismount  entities  from  Stryker  PL  WM.  Only 
B/2/1/GRND  should  dismount,  as  B/2/1/SAW  has  been  killed. 


ATC  Event: 


Name  I  Send  I  Receive  I  Delay  I  MinWait  I  MaxWait 


Dismount  C2  Federate  IWARS  5  0  0 


UpdateOneeS  AF  V  ehicle  Arrives 


Notes: 

Once  the  dismount  command  is  executed,  IWARS  updates  the  status  of  B/2/1/GRND  to 
Mounted=FALSE.  Also,  IWARS  should  enable  this  entity  once  again  for  target  acquisition,  firing, 
damage,  and  display. 


ATC  Event: 


Send  I  Receive 


IWARS  OneSAF  0 


MinWait  |  MaxWait  |  Dependencies 


0  I  60  I  Dismount 


Parameter  Name  I  Validated  Value 


Mounted  I  false 


PlatformID  B/2/1/GRND 


Execution  Steps 

# 

Step  needed  to  execute  the 
test 

Completed 

(V) 

Expected  result  for  this  step 

Successful 

(V) 

Start  RTI  executive 


Start  IWARS 


Start  ATC  test  federate 


Watch  ATC  output  for  test 
results 


RTI  executive  and  RTI  console  up  and 
running 


Federate  joins  the  current  Federation 


Federate  joins  the  current  Federation 


ATC  Test  indicates  PASSED. 


Expected  Results 

(Summary  description  of  the  expected  outcome  for  this  test  case) 


ACTUAL  RESULTS 

(Document  results  as  needed  in  addition  to  the  i///4checkedi//A  items  above) 
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TEST  EXECUTION  RECORD 

(Sign-off  of  tester  and  test  witness) 

Date:  | 

Tester 

Witness 

Printed  Name: 

Signature: 
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ANNEX  D  -  Planned  Tasks  for  Academic  Year  2009-2010 


I  WARS  Tasks 


Assigned  To  Description 


Analysis  Support 
to  XM-2 5  Program 

IWARS 

Develop  algorithms  and  data 
structures  within  IWARS  that 
enable  modeling  of  the  XM-25 
counter-defilade  target  engagement 
system. 

Command  and 
Control  Modeling 

IWARS 

Work  with  other  modeling  teams  to 
continue  toward  a  more 
robust  representation  of  command 
and  control. 

Sp ecific  tasks  include: 

Continue  to  develop  soldier  and  unit 
responses  to  intervention  types  of  commands 
to  include  movement,  orientation,  rules  of 
engagement,  and  posture. 

Support  different  rules  of  engagement  for 
different  areas  of  the  battlefield  to  represent 
clearance  of  direct  fires  and  fratricide. 

Continued  HLA 
support 

IWARS 

Continue  to  maintain  and  improve 
HLA  interaction  capabilities. 

Sp  ecific  tasks  include: 

Support M A TREX  and  FOM  updates 

Support  automatic  federation  start/stop 

Support  time  management 

Support  new  interaction  as  required  by  other 
analytical  tasks. 

Soldier  Modeling 
Team 

IWARS 

Participate  in  two  annual  soldier 
modeling  team  conferences  to 
discuss  common  concerns  with 
respect  to  development  processes, 
behaviors,  algorithms,  and  data. 

Figure  34:  IWARS  tasks  for  academic  year  2009-2010. 


OneS>1F  Tasks 


Title  Assigned  To  Description  Remarks 


Continued  HLA 
support 

OneSAF 

Continue  to  maintain  and  improve 
HLA  interaction  capabilities. 

Sp  edfic  tasks  include: 

Support MATREX  and  FOM  updates 

Support  automatic  federation  start/stop 

Support  time  management 

Support  new  interaction  as  required  by  other 
analytical  tasks. 

Analysis  Support 
to  XM-2  5  Program 

OneSAF 

Develop  algorithms  and  data 
structures  within  I  WARS  that 
enable  modeling  ofthe  XM-25 
counter-defilade  target  engagement 
system. 

Command  and 
Control  Modeling 

OneSAF 

Work  with  other  modeling  teams  to 
continue  toward  a  more 
robust  representation  of  command 
and  control. 

Sp  edfic  tasks  include: 

Continue  to  develop  soldier  and  unit 
responses  to  intervention  t^^pes  of  commands 
to  include  movement,  orientation,  rules  of 
engagement,  and  p  osture. 

Support  different  rules  of  engagement  for 
different  areas  ofthe  battlefield  to  represent 
clearance  of  direct  fires  and  fratricide. 

Support 

Integration  with 
America' s  Army 

OneSAF 

Support  architecture  and 
engineering  WTork  for  an  integration 
with  America' s  Army  that  will 
allow  America's  Anny  virtual 
soldiers  to  participate  in  a  OneSAF 
scenario. 

Integration  effort  will  include  integration  of 
America's  Army  into  the  OneSAF  SORD, 
representation  of  OneSAF  damage  and 
disp  ersion  effects  in  America' s  Army,  and 
correlation  of  terrain  via  correlated  data 
structures  and  potential  use  ofthe  OneSAF 
ERC. 

Figure  35:  OneSAF  tasks  for  academic  year  2009-2010. 


America's  Army  Tasks 


Title _ Assigned  To  Description _ Remark: 


America's  Army 
Integration 

AARDEC 

Perfbnn  architecture  and 
engineering  work  for  and 
integrati  on  with  America' s  Army 
that  will  allow  America's  Anny 
virtual  soldiers  to  participate  in  a 
Ones  A  F  scenario. 

Integiation  effort  will  include  integration  of 
America' s  Army  into  the  OneSAF  SORD , 
representation  of  OneSAF  damage  and 
dispersion  effects  in  America's  Army,  and 
correlation  of  terrain  via  correlated  data 
structures  and  potential  use  of  the  OneSAF 
ERC. 

XM-25  Prototype 

AMRDEC 

Develop  an  laser-based  XM-25 
physical  weapon  prototype  that 
allows  a  human  player  to  engage 
targets  ona  screen  with  the  XM-25. 
Integrate  that  weapon  into  the 
America's  Army  software  system. 

This  will  allow  a  human  dismounted  player 
to  employ  the  XM-25  in  a  virtual  scenario. 

Figure  36:  America’s  Army  tasks  for  academic  year  2009-2010. 


Combat X)0  Tasks 


Title 

Assigned  To 

Description 

Remarks 

Continued  HLA 

Federation 

Development 

Combat  XXI 

W ork  with  other  mo  d  eling  teams  to 
continue  HLA  development  toward 
a  more  robust  representation  of 
communications,  command  and 
control,  lethality,  and  protection. 

Sp  edfic  tasks  include: 

Build  MATREX  communications  support 

Build  MATREX  fires  architecture  support 

Build  MATREX  situation  awareness  support 

Build  behavioral  responses  to  MATREX 
Soldier  C 2  interactions. 

Complete 

MATREX 

integration 

Combat  XXI 

Continue  to  build  MATREX 
integrati  on  capabilities  that  were 
started  during  2008-2009 

Sp  edfic  tasks  indude: 

Update  interface  to  Protocore 

Update  support  forERC  and  MSDL  2.5 

Support  automatic  federation  start/stop 

Support  time  management 

Develop  data  collection  capabilities  to 
supp  ort  analysi  s. 

Develop  PEO 

Soldier  Scenarios 

Combat  XXI 

From  currently  approved  TRADOC 
sc  enaii  o  s,  work  with  U  SM A  and 

PEO  to  extract  small  scale  analysis 
vignettes  fromwdthin  those 
sc  enaii  o  s.  Thes  e  vi  gnett  es  shoul  d 
address  recurring  PEO  Soldier 
analysis  questions. 

Deliverables  will  be  MSDL  representations 
of  these  scenarios  for  use  by  all  of  the 
subordinate  models.  Assignment  of  this  task 
i  s  intended  to  leverage  the  soldi  er  analysis 
expertise  of  TRAC-WSMR. 

Soldier  Modeling 
Team 

Combat  XXI 

Participate  in  two  annual  soldier 
modeling  team  conferences  to 
discuss  common  concerns  with 
respect  to  development  pro  cesses, 
behaviors,  algorithms,  and  data. 

Figure  37:  COMBAT™  tasks  for  academic  year  2009-2010. 


^est  Point  Tasks 


Title _ Assigned  To  Description _ Remark: 


Progiam 

Management 

USMA 

Coordinate  the  execution  of  the 
deliverables  vhthin  this  effort  in 
accordance  with  established 
timelines  and  within  budget 
constraints. 

Command  and 
Control  Modeling 

USMA 

Build  ability  for  reactive  command 
and  control  into  the  federation. 

Th  ese  b  eha  vi  ors  must  b  e  fri  en  dly , 
enemy,  and  tenain  aware. 

First  effort  will  b  e  to  i  dentify  soldi  er  C  2 
behaviors  at  individual,  fire  team,  squad,  and 
platoon  level.  Then  develop  C2  interactions 
to  be  used  in  the  FOM  to  pass  these 
b  eha  vi  ors  i  nto  the  mo  del  s.  On  ce  ea  ch  mo  del 
has  built  internal  responses  to  these  C2 
behaviors,  develop  C2  federates  that  pass 
orders  to  soldi  er  entities  based  on  updated  C  2 
infonnation  about  friendly  forces,  enemy 
forces,  mission,  and  tenain. 

Communications 

Modeling 

USMA 

Support  integration  of  a  MATREX 
tool  for  communications  modeling. 

Currently,  two  different  models  are  being 
evaluated  for  this  support. 

Figure  38:  West  Point  tasks  for  academic  year  2009-2010. 


VMASC  Tasks 


Battle 

Management 
Language  fbr 
Soldier  C2 


Assigned  To  Description 


VMASC 


Support  development  of  soldier  C2 
arditecture  v^ith  D  attle 
Management  Language  (B  ML) 
representations  of  soldier  C  2  tasks. 


Support  includes  data  definition  fbr  B ML 
structures  and  prototype  implementation  of 
command  and  control  fedeiates  that  assess 
the  current  situation  and  issue  orders  to 
soldiers  using B ML. 


Figure  39:  Virginia  Modeling  Analysis  and  Simulation  Center  tasks  for  academic  year  2009-2010. 
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